On Tue, 01 Jul 2008, Miguel Angel Marchuet wrote: Hi Miguel,
> More or less I'm agree with you now. > I know the actual problem, we reduce the problem using wait's > as needed at high level classes. > Almost at windows tested platforms if you write more than > getsockopt( Socket->com, SOL_SOCKET, SO_SNDBUF, (char *) &value, &len ) > the data is lost or GPF. You has been removed this protection. Of course > is unneeded if the classes that uses it knows the problem. > Is possible Linux don't have this limitation. I do not believe that such basic functionality does not work in Windows for connected sockets. It will make TCP/IP unusable in this system for slow connections. > The actual problem is than at the write loop we don't leave time > to system API to empty his buffer. (At the moment we use sysrefresh for it) > but this is a real LOTERIA. > we need to leave enough time to the system to empty its buffer, only then > we can return to write in this buffer. If the above is true then we should find the reason in our implementation of upper level protocol (f.e. FTP) and fix it instead of reducing frequency of errors by some hacks. > Is possible a help the source code of FileZilla at sourceforge. (but it > works asynchronous) > This is information that you can found at MSDN about buffers: > > Remarks > The send function is used to write outgoing data on a connected socket. For > message-oriented sockets, care must be taken not to exceed the maximum > packet size of the underlying provider, which can be obtained by using > getsockopt to retrieve the value of socket option SO_MAX_MSG_SIZE. If the > data is too long to pass atomically through the underlying protocol, the > error WSAEMSGSIZE is returned, and no data is transmitted. TCP is not message oriented protocol. It's connected protocol and the above is true only for UDP in IP networks. The modified functions inside hbinet.c we are talking about are not used for datagram protocols at all. > The successful completion of a send does not indicate that the data was > successfully delivered. Yes but it's for UDP not TCP. > If no buffer space is available within the transport system to hold the > data to be transmitted, send will block unless the socket has been placed > in nonblocking mode. On nonblocking stream oriented sockets, the number of > bytes written can be between 1 and the requested length, depending on > buffer availability on both client and server computers. The select, > WSAAsyncSelect or WSAEventSelect functions can be used to determine when it > is possible to send more data. And we are using select() to determinate if any data can be written/read to/from connected socket so for us it's unimportant if it's in blocked or unblocked mode. The OS will accept/return as much bytes as possible without blocking application and it will return exact number of bytes transfered between application and its internal buffer. Upper level code has to only check this value because not all bytes can send/received. > Calling send with a zero len parameter is permissible and will be treated > by implementations as successful. In such cases, send will return zero as a > valid value. For message-oriented sockets, a zero-length transport datagram > is sent. > The flags parameter can be used to influence the behavior of the function > beyond the options specified for the associated socket. The semantics of > this function are determined by the socket options and the flags parameter. > The latter is constructed by using the bitwise OR operator with any of the > following values Exactly but I know this definition and it does not change anything for us. We are talking about TCP not UDP. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
