Maurilio before operated by chance, because the buffer actual default system is 8Kb windows, and just luckily it worked in most cases.
Has tested performance with the new configuration ? In my test is much much much faster now. Please test it before change the code. The buffer was never 1.4 Kb. Just read the buffer 8Kb of 1.4 in 1.4 Kb. This was a very serious mistake, because the system has never guaranteed a buffer 8Kb, but in some cases it is reduced below 1.4 Kb, in this case GPF will be produced. Now that is guaranteed never use more than half of the buffer that the system will allow us to. If we reduce system buffer to 1,4Kb instead of 8kb (default), we lost data. As we have said before, as a buffer can fix most suitable to each protocol separately. 64Kb for FTP, SMTP, POP3 and HTTP And for the rest of protocols, ceases the value that was already using default system is usually 8Kb You can contact with me at messenger [EMAIL PROTECTED] and we can speak in Italian or Spanish better. Best regards, Miguel Angel Marchuet Maurilio Longo escribió: > 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xharbour-developers >> > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/xharbour-developers
