On Tue, 01 Jul 2008, Miguel Angel Marchuet wrote: Hi Miguel,
> Is possible that i speak bad English. > but iRcvBufSize/iSndBufSize are imperatively needed without it > we will need to call every transfer to getsockopt to know the system buffer > Snd and Rcv > to know his size. We do not need to know the system buffer at all so we do not need to call this function. The OS will accept as much bytes as it will can and as it will be optimal. > If we use 1400 hard coded then the code can produce GPF. (now it is removed) First: I do not want to reintorduce hardcoded 1400 bytes limit. It was wrong just like now it's wrong the limit we have inside iRcvBufSize/ iSndBufSize. Thank you for removing the smaller limit but intorducing new one only bigger is not necessary at all and may only reduce the speed. It's also hardcoded limit because you do not know how many free bytes is left in IO buffer. You do not even know what is the real size of send/receive buffer because SO_RCVBUF/SO_SNDBUF informs kernel only about _suggested_ buffer size and the real buffer size can be different and it's out of normal user control. Usually the internal buffer size is doubled so as long as you will use iRcvBufSize/iSndBufSize to limit size of single read/write operation then you will be reducing optimal transfer. We should remove all such limits and allow the kernel to accept as much bytes as it like and retrieve as much bytes as available. Second: if it GPFs then the bug is in some other code (probably in TIP library) and it has to be fixed or buggy code removed from SVN repository. Adding workarounds for bugs in upper level code to lower level code instead of fixing problem only increased it. In general adding workarounds for GPFs instead of fixing real reasons is the worst possible thing because bugs are not fixed and sooner or later will be exploited by some other code. Additionally the code with unnecessary hacks is harder to understand and fix. > Now we remove this unneeded fragmentation increasing buffer as possible, > using system default values > saved at iRcvBufSize/iSndBufSize. Not removed but moved to the level hardcoded inside: iRcvBufSize/ iSndBufSize. I only want to really _FULLY_ remove it. > Now you can too try to increase this values to to make packets bigger or > lower. But never use > hard coded 1400 because the system can put a minor default buffer size. Or > system can works > too slow to works with full buffer. The 1400 bytes limit was wrong and it has to be eliminated. But replacing one limit with another one just like in your modification is not enough. Please also remove the limit we have now in iRcvBufSize/ iSndBufSize. > Now is corrected and we now use the correct buffer size. No, It isn't. > You prefer to call every time to getsockopt to known the buffer size > or you prefer to use iRcvBufSize/iSndBufSize, technically is the same. No. I do not want to call getsockopt at all. I'll fix send/receive code myself and please look at the final version because it looks like you do not understand what I'm talking about. Sorry - it's probably my fatal English. > We need to know it to protect the transfer. No. If the above is true for upper level protocol using TCP/IP then it means that we have bugs in this upper level implementation. Please try to locate and fix them. > we now use this values (iRcvBufSize/iSndBufSize) to establish the buffer > transfer > at the different protocols, than always will be lower than > iRcvBufSize/iSndBufSize. Miguel, please read something about TCP/IP implementation and what SO_RCVBUF/SO_SNDBUF because it really makes sth different then you think it does. > but you can't use another buffer size without a risk of GPF. I can use any buffer size without risk of GPF in valid code. > Actually code is tested at the last 4 months without GPF or other problems. But it's not optimal and probably still buggy. > Of course, it can be better if at the future we can use MT to make > asynchronous transfers > or use too multi socket transfers to accelerate it. Asynchronous transfer is different thing. Please do not mix it now. > We had serious problems of transfer speed, and now is solved and without > GPF or lost data. Again, valid code should not GPF. This modification does not fixed any potential GPF and if it helps you then you only confirm that we still have some buggy code which have to be fixed. This buggy code is probably inside TIP library. I've never used this library because I have my own one but maybe someone similar with it can locate the problem. I'll check if hbinet.c does not have some bugs. I adopted this code from xHarbour to Harbour but I've never made any serious cleanup. I'm leaving it to the moment when I'll introduce public C level harbour API for inet sockets and I'll remove the limit inside iRcvBufSize/iSndBufSize. If it exploits GPFs then even better because it will be easier to locate the real problem. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
