Re: [twsocket] Bug in TCustomWSocket
Éric Fleming Bonilha wrote:
HI
I don´t know if this bug was already fixed on newer releases of
TWSocket, if yes, sorry for the mail
Éric,
Thanks, I just checked in rev. #700.
--
Arno Garrels
On unit OverbyteIcsWSocket
procedure TCustomWSocket.SetSocketRcvBufSize(BufSize : Integer);
var
iStatus : Integer;
optlen : Integer;
begin
optlen := SizeOf(BufSize);
{$IFDEF CLR}
iStatus := WSocket_setsockopt(FHSocket, SOL_SOCKET, SO_RCVBUF,
BufSize, optlen);
{$ELSE}
iStatus := WSocket_setsockopt(FHSocket, SOL_SOCKET, SO_RCVBUF,
PAnsiChar(@BufSize), optlen);
{$ENDIF}
if iStatus = 0 then
FSocketSndBufSize := BufSize
else
SocketError('setsockopt(SO_RCVBUF)');
end
if iStatus = 0 then
FSocketSndBufSize...
You are storing the buf size on the wrong variable, it should be
FSocketRcvBufSize
Eric
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
I've removed the parsing and processing of data from the OnDataAvailable. The event handler now basically contains ReceiveStr() and PostMessage(). I'm still having the same problem though :( It seems that this problem is not triggered by doing something wrong in the OnDataAvailable event handler, but somewhere else. I'm starting to think it's something in the sending of data since that keeps coming back in the callstack (see attached callstack). Hoping someone can give me a hint. Merijn |--| |7C810E31|kernel32.dll| | |WriteFile | | |7C90D590|ntdll.dll | | |NtClose | | |7C809BA5|kernel32.dll| | |CloseHandle | | |7C809B67|kernel32.dll| | |CloseHandle | | |006BF6B2|AviaVox.exe |ServerTimedSocket.pas|TServerTimedSocket |_Log|301[17] | |71AA150A|WS2HELP.dll | | |WahReferenceContextByHandle | | |71AB4376|WS2_32.dll | | |WSARecv | | |71AB437D|WS2_32.dll | | |WSARecv | | |71AB4318|WS2_32.dll | | |WSARecv | | |71AD2E9E|wsock32.dll | | |recv| | |005C569F|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_recv |2277[3] | |005C6B00|AviaVox.exe |WSocket.pas |TCustomWSocket |DoRecv |3825[0] | |005CC772|AviaVox.exe |WSocket.pas |TCustomSocksWSocket |DoRecv |6759[2] | |0055F9C4|AviaVox.exe |PostPone.pas |TPostPone |PostPone|80[1]| |006BF84E|AviaVox.exe |ServerTimedSocket.pas|TServerTimedSocket |OnDataAvailable |333[20] | |71AB44E5|WS2_32.dll | | |WSAIoctl| | |71AB4489|WS2_32.dll | | |WSAIoctl| | |71AB4536|WS2_32.dll | | |ioctlsocket | | |005C5398|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2136[3] | |005C5374|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2133[0] | |005C7229|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4226[28] | |7C80A424|kernel32.dll| | |CompareStringW | | |7C80A37E|kernel32.dll| | |CompareStringW | | |7C90D8ED|ntdll.dll | | |NtDeviceIoControlFile | | |71AB42F5|WS2_32.dll | | |send| | |71AB42FC|WS2_32.dll | | |send| | |005C52E7|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_send |2098[3] | |005C2808|AviaVox.exe |WSockBuf.pas |TBuffer |Peek|212[0] | |005C6D8A|AviaVox.exe |WSocket.pas |TCustomWSocket |TryToSend |4006[16] | |005C6F07|AviaVox.exe |WSocket.pas |TCustomWSocket |TryToSend |4070[80] | |7E41CBB3|USER32.dll | | |PostMessageA| | |7E41CB69|USER32.dll | | |PostMessageA| | |005C710A|AviaVox.exe |WSocket.pas |TCustomWSocket |Send|4164[31] | |005C715A|AviaVox.exe |WSocket.pas |TCustomWSocket |SendStr |4177[2] | |006BFA70|AviaVox.exe |ServerTimedSocket.pas|TServerTimedSocket
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Sorry for the late reply, we've had an expo this week which needed some (a lot) of attention. I didn't find any calls to ProcessMessages(). This socket runs in it's own thread, so a call to ProcessMessages() would have been out of place. I did find something else though. Even though the server socket had it's MultiThreaded property set to true, the client socket it spawns did not have this property set to true explicitly. Therefor ICS was calling ProcessMessages() itself now and then. Maybe it would be a good idea to let TCustomWSocketServer set Multithreaded of newly created clients to the same value it has itself? WSocketS.pas around line 360. Anyway, back to my problem, because it's still here :| All sockets have now their MultiThreaded property set to true. I removed the wsoNoReceiveLoop again, because it didn't seem to have to do anything with the problem. I've added some logging when the problem occurs, so I have some new information. The OnDataAvailable event is never triggered from within itself. So it seems not to be caused by calling a messagepump in the event, which triggers the event again! If in the loop, in each event there is no data to receive. If in the loop, in each event, error = 0 If in the loop, in each event I note LastError before, and after I call ReceiveStr(). I do this because TCustomWSocket.ASyncReceive, which triggers the event, looks at FLastError to decide it should call the event again. In both cases I had the extended logging, LastError was set to a non-zero value. In the first case it was 10054, and the second case it was 10034. LastError was the same before and after the call to ReceiveStr(). Besides the extended logging, I built in a mechanism which automatically dumps a call stack of the thread the socket runs in, 60 seconds after I get stuck in the 'loop'. Of course this call stack is just a snapshot somewhere in the loop, but since I got the same call stack a couple of times now, I'm pretty sure this is how the OnDataAvailable event is triggered. The strange thing is, that there always seems to be a strange 'jump' in the call stack which I can't explain (or probably which I don't understand): It goes from Do_FD_READ to AsyncReceive (normal), but before AsyncReceive is actually run, it jumps to TriggerDataSent (?). After that some other strange things in the call stack. See the call stack here, the calls to CheckForPendingMessages are calls to methods which call the messagepumps for different controls, amongst which TCustomWSocket.ProcessMessages(). I really hope someone can give me some more pointers in the right direction! callstack: |7C90E9FD|ntdll.dll | | |NtWriteFile | | |7C810E10|kernel32.dll| | |WriteFile | | |006C268B|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|291[16] | |006C2528|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|275[0] | |006C27DB|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |OnDataAvailable |305[8] | |005CBFA0|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5970[24] | |005CBF80|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5946[0] | |005CDA0B|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6504[2] | |005CD9E0|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6502[0] | |005CE90C|AviaVox.exe |WSocket.pas |TCustomLineWSocket |TriggerDataAvailable|7065[7] | |005C8C58|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4204[6] | |005C6DB3|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2136[3] | |005C6D8C|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2133[0] | |005C8CDD|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4226[28] | |71AB42F5|WS2_32.dll | | |send| | |71AB42FC|WS2_32.dll | | |send| | |005C6CF7|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_send |2098[3] | |005CBEDC|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerSendData |5907[0] | |005C87A9|AviaVox.exe |WSocket.pas |TCustomWSocket
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
I just noticed the layout of the call stack got kind of messed up, so I've attached as a text file. Merijn Bosma wrote: Sorry for the late reply, we've had an expo this week which needed some (a lot) of attention. I didn't find any calls to ProcessMessages(). This socket runs in it's own thread, so a call to ProcessMessages() would have been out of place. I did find something else though. Even though the server socket had it's MultiThreaded property set to true, the client socket it spawns did not have this property set to true explicitly. Therefor ICS was calling ProcessMessages() itself now and then. Maybe it would be a good idea to let TCustomWSocketServer set Multithreaded of newly created clients to the same value it has itself? WSocketS.pas around line 360. Anyway, back to my problem, because it's still here :| All sockets have now their MultiThreaded property set to true. I removed the wsoNoReceiveLoop again, because it didn't seem to have to do anything with the problem. I've added some logging when the problem occurs, so I have some new information. The OnDataAvailable event is never triggered from within itself. So it seems not to be caused by calling a messagepump in the event, which triggers the event again! If in the loop, in each event there is no data to receive. If in the loop, in each event, error = 0 If in the loop, in each event I note LastError before, and after I call ReceiveStr(). I do this because TCustomWSocket.ASyncReceive, which triggers the event, looks at FLastError to decide it should call the event again. In both cases I had the extended logging, LastError was set to a non-zero value. In the first case it was 10054, and the second case it was 10034. LastError was the same before and after the call to ReceiveStr(). Besides the extended logging, I built in a mechanism which automatically dumps a call stack of the thread the socket runs in, 60 seconds after I get stuck in the 'loop'. Of course this call stack is just a snapshot somewhere in the loop, but since I got the same call stack a couple of times now, I'm pretty sure this is how the OnDataAvailable event is triggered. The strange thing is, that there always seems to be a strange 'jump' in the call stack which I can't explain (or probably which I don't understand): It goes from Do_FD_READ to AsyncReceive (normal), but before AsyncReceive is actually run, it jumps to TriggerDataSent (?). After that some other strange things in the call stack. See the call stack here, the calls to CheckForPendingMessages are calls to methods which call the messagepumps for different controls, amongst which TCustomWSocket.ProcessMessages(). I really hope someone can give me some more pointers in the right direction! callstack: |7C90E9FD|ntdll.dll | | |NtWriteFile | | |7C810E10|kernel32.dll| | |WriteFile | | |006C268B|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|291[16] | |006C2528|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|275[0] | |006C27DB|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |OnDataAvailable |305[8] | |005CBFA0|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5970[24] | |005CBF80|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5946[0] | |005CDA0B|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6504[2] | |005CD9E0|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6502[0] | |005CE90C|AviaVox.exe |WSocket.pas |TCustomLineWSocket |TriggerDataAvailable|7065[7] | |005C8C58|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4204[6] | |005C6DB3|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2136[3] | |005C6D8C|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2133[0] | |005C8CDD|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4226[28] | |71AB42F5|WS2_32.dll | | |send| | |71AB42FC|WS2_32.dll | | |send| | |005C6CF7|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_send |2098[3] | |005CBEDC|AviaVox.exe |WSocket.pas
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
On Apr 11, 2008, at 03:39, Merijn Bosma wrote: In case I am, could that explain this behavior? I'm not calling the message pump when I'm receiving no data, so shouldn't that break the loop if it was there? You also may want to trace deep into all the procedures you call from the event handler to see if any of them ultimately call the message pump. dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Merijn Bosma wrote: Hello, Yesterday evening we've found out that this problem still occurs, even with wsoNoReceiveLoop set. The symptoms are the same: - OnDataAvailable event is triggered continuously (close to 14000 times per second) - ReceiveStr() is called every time, returning no data - Error is always 0 in the events - The event keeps being triggered until we shut down the application. This is not a high speed stream, we sent only control data, so approx up to 100 bytes every few seconds. I'm I doing something stupid or is there something else going wrong here? If it's not me, is there any way for to determine whether this is a problem with ICS, or with the Windows call stack itself? Francois PIETTE wrote: One possible explanation were that anytime OnDataAvailable returns, just a few _new_ bytes are available in winsock buffer. Could be possible due to the background thread winsock creates internally with non-blocking sockets, though I'm not aware of how winsock works under the hood. When in this situation, we got a few hundred calls a second, for an unlimited time, where normally it's one every few seconds. I agree with you, it could be a possible cause, but very unlikely. Do you receive data each time you call ReceiveStr ? If yes, then probably you have a fast network, and your application becomes CPU bound. That's the thing, I don't receive any data. At least not using ReceiveStr() btw: Since you don't use line mode, I strongly suggest you avoid ReceiveStr and instead use Receive with a fixed buffer. Calling ReceiveStr will force the runtime to create new string and copy data into it, and probably youthen copy data elsewhere for processing. All this is very CPU intensive. The best way to design a high performance application is to use a fixed buffer (which may be dynamically allocated but not each time you receive data). And use the buffer as close as possible of the processing each time you copy data, each time you consume CPU and memory for nothing. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Hi, - OnDataAvailable event is triggered continuously (close to 14000 times per second) Do you call the message pump from OnDataAvailable, directly or indirectly (i.e. Application.ProcessMessages, any Showmessage() or a VCL-dialog)? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html Merijn Bosma wrote: Merijn Bosma wrote: Hello, Yesterday evening we've found out that this problem still occurs, even with wsoNoReceiveLoop set. The symptoms are the same: - OnDataAvailable event is triggered continuously (close to 14000 times per second) - ReceiveStr() is called every time, returning no data - Error is always 0 in the events - The event keeps being triggered until we shut down the application. This is not a high speed stream, we sent only control data, so approx up to 100 bytes every few seconds. I'm I doing something stupid or is there something else going wrong here? If it's not me, is there any way for to determine whether this is a problem with ICS, or with the Windows call stack itself? Francois PIETTE wrote: One possible explanation were that anytime OnDataAvailable returns, just a few _new_ bytes are available in winsock buffer. Could be possible due to the background thread winsock creates internally with non-blocking sockets, though I'm not aware of how winsock works under the hood. When in this situation, we got a few hundred calls a second, for an unlimited time, where normally it's one every few seconds. I agree with you, it could be a possible cause, but very unlikely. Do you receive data each time you call ReceiveStr ? If yes, then probably you have a fast network, and your application becomes CPU bound. That's the thing, I don't receive any data. At least not using ReceiveStr() btw: Since you don't use line mode, I strongly suggest you avoid ReceiveStr and instead use Receive with a fixed buffer. Calling ReceiveStr will force the runtime to create new string and copy data into it, and probably youthen copy data elsewhere for processing. All this is very CPU intensive. The best way to design a high performance application is to use a fixed buffer (which may be dynamically allocated but not each time you receive data). And use the buffer as close as possible of the processing each time you copy data, each time you consume CPU and memory for nothing. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Arno Garrels wrote: Hi, - OnDataAvailable event is triggered continuously (close to 14000 times per second) Do you call the message pump from OnDataAvailable, directly or indirectly (i.e. Application.ProcessMessages, any Showmessage() or a VCL-dialog)? I'm digging through code right now just to be sure. In case I am, could that explain this behavior? I'm not calling the message pump when I'm receiving no data, so shouldn't that break the loop if it was there? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Merijn Bosma wrote: Arno Garrels wrote: Hi, - OnDataAvailable event is triggered continuously (close to 14000 times per second) Do you call the message pump from OnDataAvailable, directly or indirectly (i.e. Application.ProcessMessages, any Showmessage() or a VCL-dialog)? I'm digging through code right now just to be sure. In case I am, could that explain this behavior? I think so. I'm not calling the message pump when I'm receiving no data, so shouldn't that break the loop if it was there? The event handler may be reentered, so don't call the message pump from there. If you want i.e. display a dialog you could post a custom message and from its message handler pop up the dialog. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? (regarding wsoNoReceiveLoop)
Merijn Bosma wrote: I've been using ICS for quite a while now, and a few days ago I came across something strange. One of our larger customers had some extra modules installed, causing a lot of more tcp clients connecting to the tcp server. Every now and then (somewhere between 1 minute and 3 hours) the tcp server would get up to 100% cpu utilization out of the blue. After some searching we discovered that this was caused by the OnDataAvailable event for one of the connected clients being called continuously. Now the mystery: If I understood correct, you can get an endless loop if you don't read all received data in the OnDataAvailable event. You get a real infinite loop only if you called Receive() with a buffer size of zero. The event will keep being fired until all data is read, unless you add wsoNoReceiveLoop. With option wsoNoReceiveLoop turned on OnDataAvailable will also trigger again and again as long as data is available. The difference is that the app. is given a chance to call its message pump between two OnDataAvailable events. As a result CPU utilization becomes lower. This may however also lower transfer rates a bit. The thing is that we _always_ call ReceiveStr() in the OnDataAvailable event, I think this should always read all data received. Depends on LineMode, if LineMode is TRUE ReceiveStr() just reads a single line. Is this a bug in ReceiveStr() or a bug regarding wsoNoReceiveLoop? I don't think it's a bug, wsoNoReceiveLoop is an option turned off by default for backwards compatibility. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? (regarding wsoNoReceiveLoop)
Thanks for your reply! Arno Garrels wrote: You get a real infinite loop only if you called Receive() with a buffer size of zero. Which is not the case The thing is that we _always_ call ReceiveStr() in the OnDataAvailable event, I think this should always read all data received. Depends on LineMode, if LineMode is TRUE ReceiveStr() just reads a single line. LineMode is false I don't think it's a bug, wsoNoReceiveLoop is an option turned off by default for backwards compatibility. I'm really looking for an explanation of what happened, so I can confirm the bug is really fixed. Facts: - 100% cpu utilization caused by OnDataAvailable being called in a loop (sync, so no change for the message pump to work) - Linemode = false - we call ReceiveStr() on _every_ OnDataAvailable event - when wsoNoReceiveLoop is set, we don't have this problem anymore these things seem to contradict each other? It of course is possible that with wsoNoReceiveLoop set we still have the same problem, but we don't notice it because the message pump has a change to kick in. Is there any way I can get my fingers around this? Reading it all again, I'm still coming to the same conclusion: either bug in ReceiveStr(), bug in handling of wsoNoReceiveLoop, or me being stupid and don't understanding things correctly. Can anybody shed some light? :p -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? (regarding wsoNoReceiveLoop)
Merijn Bosma wrote: again, I'm still coming to the same conclusion: either bug in ReceiveStr(), bug in handling of wsoNoReceiveLoop, Again I don't agree because as you described it works as documented. Quoted from the unit comment section: Added ComponentOptions property with currently only one options wsoNoReceiveLoop which disable a receive loop in AsyncReceive. This loop breaking was suggested by Davie [EMAIL PROTECTED] to lower resource usage with really fast LAN and large transfers. By default, this option is disabled so there is no change needed in current code. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? (regarding wsoNoReceiveLoop)
I'll reply to both your mails in a single one: One possible explanation were that anytime OnDataAvailable returns, just a few _new_ bytes are available in winsock buffer. Could be possible due to the background thread winsock creates internally with non-blocking sockets, though I'm not aware of how winsock works under the hood. When in this situation, we got a few hundred calls a second, for an unlimited time, where normally it's one every few seconds. I agree with you, it could be a possible cause, but very unlikely. Arno Garrels wrote: Merijn Bosma wrote: again, I'm still coming to the same conclusion: either bug in ReceiveStr(), bug in handling of wsoNoReceiveLoop, Again I don't agree because as you described it works as documented. Quoted from the unit comment section: Added ComponentOptions property with currently only one options wsoNoReceiveLoop which disable a receive loop in AsyncReceive. This loop breaking was suggested by Davie [EMAIL PROTECTED] to lower resource usage with really fast LAN and large transfers. By default, this option is disabled so there is no change needed in current code. Ok, but can the behavior be explained concerning what's said above? tx, Merijn -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? (regarding wsoNoReceiveLoop)
One possible explanation were that anytime OnDataAvailable returns, just a few _new_ bytes are available in winsock buffer. Could be possible due to the background thread winsock creates internally with non-blocking sockets, though I'm not aware of how winsock works under the hood. When in this situation, we got a few hundred calls a second, for an unlimited time, where normally it's one every few seconds. I agree with you, it could be a possible cause, but very unlikely. Do you receive data each time you call ReceiveStr ? If yes, then probably you have a fast network, and your application becomes CPU bound. btw: Since you don't use line mode, I strongly suggest you avoid ReceiveStr and instead use Receive with a fixed buffer. Calling ReceiveStr will force the runtime to create new string and copy data into it, and probably youthen copy data elsewhere for processing. All this is very CPU intensive. The best way to design a high performance application is to use a fixed buffer (which may be dynamically allocated but not each time you receive data). And use the buffer as close as possible of the processing each time you copy data, each time you consume CPU and memory for nothing. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
