2010/1/3 Doriano Blengino <doriano.bleng...@fastwebnet.it>: > Kadaitcha Man ha scritto:
> After a few minutes I suggested that a timeout could simplify things, I > changed my mind. It would not be a totally bad idea but, as most other > mechanisms, it has its problems. First, what is the right timeout? It is either 0 for no timeout or it is set by the application. http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.receivetimeout%28VS.80%29.aspx http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.sendtimeout%28VS.80%29.aspx $ man socket SO_RCVTIMEO and SO_SNDTIMEO Specify the receiving or sending timeouts until reporting an error... perl: timeout([VAL]) Set or get the timeout value associated with this socket. If called without any arguments then the current setting is returned. If called with an argument the current setting is changed and the previous value returned. As you can see, the idea of a timeout is not a strange one to many languages on either Unix, Linux or Windows. In fact, I'd say it is an absolute necessity. And if you are using the OS socket, which you seem to be doing, then why should Gambas hide a property that is already available to C/C++ and even script programmers? > Second, if a timeout occurs, how many data has been sent? Again, that is not the business of the socket. The business of the socket is alert the program that a problem exists, nothing more. > anyway, this is a truely complicated matter. It is only complicated if you believe that the socket should poke its nose into business it shouldn't :) If the connection goes belly up, the socket can, at best, know how many bytes it sent into the ether, but it cannot ever know how many of those bytes went into hyperspace never to be seen again. How can it? It's not possible. That's why the client and server have to deal with the problem between themselves. Really, there is nothing strange in a having timeout. It is up to the client and the server to work out what to do if the connection goes down. It is not up to the socket. ------------------------------------------------------------------------------ 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