2010/1/3 Benoît Minisini <gam...@users.sourceforge.net>: >> > 2010/1/2 Benoît Minisini <gam...@users.sourceforge.net>: >> >> Please provide the source code of the network communication, >> >> otherwise I can't see what you are doing exactly. >> >> Ok, here is some code that adequately reproduces the problem, and the >> exact same code with a smaller chunk of text that does not have the >> problem. >> >> SocketOK works. >> >> ChokeASocket is exactly 100% the same code except that it has a 48k >> file to transmit to the remote server. >> >> The remote server is already setup in the code so just run it. I >> recommend running SocketOK first. I have tried this with four >> independent servers and get the same result, SocketDeath. >> >> Regards, >> > > OK, I identified the problem: > > By default, Socket are in non-blocking mode (Blocking property set to False).
Blocking property? On a socket? <checks> AAARGGGGHHHHH! I checked high and low in the early days of this project on how to block a socket; it's what I wanted to do from the start. The documentation says not a single thing about such a property for Socket, unless you know that Blocking is inherited from Stream, which I only just this moment discovered. http://gambasdoc.org/help/comp/gb.net/socket I will see about updating the Socket page and add the Blocking property to the list of inherited properties. > So writing to it a big chunk fails. The bug is that instead of raising an > error during the Write instruction, it fails silently. > > By having a blocking socket, your program works. > > So, two remarks: > > You should set the Blocking property to True in the Ready event. Yes, I'll look at that, but why in the Ready event? Would there be any disadvantage or problem with setting the socket to block permanently when it is instantiated and its properties setup in code? Also, if it is set in the Ready event, would it needlessly get set again every time the socket became ready? > Maybe the Write instruction is silly: if the user wants to write a big chunk > of bytes, we should temporarily enter blocking mode while writing. Or not? I'm sorry, I don't understand "we". Do you mean the development team? I assume you do, from your later comments. Whatever you come up with, I would be all for the socket taking care of as much socket business as it should or could. > It is not evident, because you may want to write on the socket only during its > Write event and need to never block. The problem is you can't know how many > bytes to send without sending them, and Gambas at the moment does not tell how > many bytes were successfully sent to the socket in one shot. > > Or maybe Socket must be blocking by default? I think that sounds like a good idea. > Some thinking is needed there... Well, I'm glad I made that happen :) Just something for you to consider, in my opinion there is nothing wrong with synchronous sockets, or synchronous ServerSockets for that matter. Not only is synchronous mode appropriate in some circumstances, it would greatly reduce the complexity of managing events for an asynch object, especially in circumstances where an exact sequence of steps must take place on either end of the socket before anything gets done, as is the case in the example I sent you. That would make even more sense on a high speed network or where a client and server were on the same machine. You would also need a timeout setting. Yes, that would make the application block during transmission, but that's what the Busy cursor is for :) Regards, ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user