Miguel,
I'm sorry I cannot make my english better than this, so I try one more time
before giving up with this issue:
don't hardcode 64Kb buffers inside inet.c, don't set any kind of buffer there,
simply use what the OS has as default buffer and do 1.4Kb reads/writes as it
was before (BTW, previous code worked for everyone for several years, so it
cannot be so bad).
Then, inside ftp code, or your own code, using your just added
InetSetSndBufSize( pSocket, nSizeSendBuffer )
InetSetRcvBufSize( pSocket, nSizeReciveBuffer )
InetGetSndBufSize( pSocket )
InetGetRcvBufSize( pSocket )
functions set send/receive buffer to what you like/think can be best for you.
I think that low-level code should not make assumptions on the use of it that
higher level code will do, so setting SO_SNDBUF/SO_RCVBUF inside inet.c is
plain wrong, IMHO.
Best regards.
Maurilio.
Miguel Angel Marchuet wrote:
>> My point is:
>>
>> before: we were using OS provided buffers (which you can retrieve with
>> getsockopt()) and read/write to/from it at 1.4Kb max per operation; we did
>> not
>> care to set socket buffers since OS uses a default size (maybe you have 8Kb
>> default, mine could be bigger or smaller) which is enough for every kind of
>> operation (but sometimes can be under optimal for a given kind of traffic).
>>
>> now: we force 64Kb, then in ftp you reduce it to 32Kb (so why set it at 64Kb
>> inside inet.c if 64Kb can cause data corruption?). After this change, we all
>> have 64Kb forced buffers for every kind of transmission we handle (BTW, code
>> inside inet.c is repeated a couple of times, why not add a single c-only
>> function which receives a socket and sets it at a certain size?).
>
> Is needed to establish a buffer size more bigger than you can read to have
> enough
> time to read all meanwhile data transfers. If the buffer had the same size as
> we read
> then we always lost data, because in the time between readings, the buffer is
> filling
> without being able to continue to meet and these data will be lost.
>
> From 64k are usable 32k for security, and is a good default if you test
> speed over
> ftp, smtp and http. I don't test other protocols.
>
> We now not force to 64, only try, and use better buffer if is possible, but
> respect
> OS memory limitations, in some cases this buffer can be reduced to 200b for
> example
> and Inet works now too.
>
>> In my opinion a better solution, and a solution which is guaranteed to work
>> at
>> least as good as it was working before, would have been to add
>> SetSocket[Snd/Rcv]Buffer() calls so that if someone needs to change the OS
>> default it can do it from .prg code _but_ leave the code of inet.c as it was.
>
> These features have already been added:
>
> InetSetSndBufSize( pSocket, nSizeSendBuffer )
> InetSetRcvBufSize( pSocket, nSizeReciveBuffer )
>
> InetGetSndBufSize( pSocket )
> InetGetRcvBufSize( pSocket )
>
> Other protocols can reduce easily using this functions to change dynamically
> his buffers after connection.
>
>> Then, inside ftp client .prg code you could have set buffers to 32Kb since
>> this seems to give better results. Maybe my code works better with smaller
>> buffers, who knows, PPOE, dial-up connections with a small mtu and all the
>> weird thing that are out there.
>>
>
> FTP needs to establish 64 buffer size for use readings of 32 for not lost
> data entries.
>
> I study the way to set properly defaults at each protocol.
>
> Best regards,
> Miguel Angel Marchuet
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> xHarbour-developers mailing list
> xHarbour-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>
--
__________
| | | |__| Maurilio Longo
|_|_|_|____| farmaconsult s.r.l.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
