On Wed, 29 Jul 2009, Przemyslaw Czerpak wrote:
> I'm not very familiar with TIP code but some user messages I've seen
> suggested that some things do not work correctly, i.e. as workaround
> for some problems with FTP TIP client Miguel introduced new functions
> hb_inet[SG]et{Rcv,Snd}BufSize() and used them in HBTIP code.
> To clarify: there is no even single technical reason to modify internal
> IP buffer size in such context so above modifications should never appear
> in core code (BTW in xHarbour above modifications seriously broke INET
> code and it's broken so far though users are sending self contain examples
> to xHarbour news group). Anyhow Miguel added such functionality (probably
> without understanding what it exactly does) so I guess it helped him to
> hide real bugs in some other code which we should find and fix because
> above workaround is not real fix so the problem can appear with some
> other conditions.And here is confirmation that he is changing things he does not understand: ,--------------------------------------------------------------------------- | 2009-07-23 12:30 UTC+0100 Miguel Angel Marchuet <soport...@dsgsoftware.com> | * include\hbipapi.h | * source\rtl\hbip.c | * modified buffers as recomend microsoft: | To modify the socket send buffer, use the Windows Sockets getsockopt function to determine the current | socket send buffer size (SO_SNDBUF), and then use the setsockopt function to set the socket send buffer size. | When you are finished, the SO_SNDBUF value must be at least 1 byte larger than the program send buffer size. | Modify the send call or the WSASend call to specify a buffer size at least 1 byte smaller than the SO_SNDBUF | value. In the earlier example in the "Cause" section of this article. | http://support.microsoft.com/kb/823764/en-us/ `--------------------------------------------------------------------------- He didn't understand above MS description or he didn't know the code he copied to source/rtl/hbip.c. In this code only blocking IO sockets are used to send and receive data so the 1-st condition necessary to exploit the problem with ACK delay does not exist so it's not necessary to introduce described hack with send buffer size as workaround for fatal for performance of TCP stack implementation in MS-Windows. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
