On Mon, 30 Jun 2008, Miguel Angel Marchuet wrote: Hi Miguel,
> iRcvBufSize/oSndBufSize now contents the maximum buffer assigned by > system, we need to know this value > saved at iRcvBufSize/oSndBufSize, because we can use only half of this > buffer for safe, almost If the above is true then out upper level code (TIP) library should be removed from SVN. I cannot imagine that we have broken code which needs such tricks and I cannot accept that lowlevel code is hacked to fix some bugs which are in other places. Please fix the reasons or if you do not understand sth then please ask someone who can help you. Anyhow manipulating buffer size to fix bugs in upper level protocol implementation (if any) is yet another thing (3-rd). > meanwhile we work with synchronous buffers. > IMPORTANT this buffers don't have a fix size almost at windows platform, > it depends of the free memory > system, by default 8kb. Normally we can try to increase it as necessary. > for example we have good rates > using 64kb bytes to transfer ftp and 16kb for http. > for this reason we can't remove iRcvBufSize/oSndBufSize, we need to know > this values to not use more > than half buffer to save. We do not need these variables at all. >From the begining you are mixing two different things: the internal IP buffer size and fragmentation in read/write operation. If you want to change IP buffer then please do it. That's your choice. > Test using more size some time produce lost of data (windows platforms) > is possible that linux works better > and is possible to use full system buffer size. > You can say to me what is the default system buffer size at linux > platforms ? It has nothing to the problem in the code which introduce additional fragmentation. It makes it from begining. This fragmentation should be removed. Instead of removing it you increased the peaces to the size of IP buffer. It reduce the overhead but it does not resolve the problem. It's enough to _FULLY_ eliminate unnecessary fragmentation. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
