2010/1/3 Doriano Blengino <doriano.bleng...@fastwebnet.it>: > after a timeout occurs, one can only assume that > the entire write has failed, even if, in fact, some data has been > succefully written.
Yes, you are quite correct, but the problem of partial data transfer due to a timeout is not a problem for the socket to sort out. It is for the server and client to sort out between themselves. If you look at the sample code I attached earlier, there is this line: Private Const MULTILINE_BLOCK_TERMINATOR As String = "\r\n.\r\n" A CRLF "." CRLF sequence is the RFC3977 "termination octet". The server knows it has not got the data that client said it is sending until it gets the termination octet. If the socket goes quiet and the termination block has not been received after a specific time interval then the server closes the connection and discards the transaction. Again, I fully agree with your thoughts up there, but I genuinely question if it is a problem that the socket itself needs to be concerned about. In my view, it does not and should not. The socket only need alert the programmer to a timeout and try to gracefully exit. The socket shouldn't be taking care of network communications problems where a properly signalling pair of entities should already have a set of agreed rules to abide by when a transmission is incomplete. 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