> to my problem I found something out: if I disable processing of these > commands up to 100.000 and more are stored in the queue, so the sending > and receiving of them via ICS works well.
:-) > The receiving uses a tight loop to extract all commands out of the > ringbuffer and stores them in the queue. After storing one command the > processing thread will be informed via PostThreadMessage, but obviously > it doesn't come to work, maybe that other loop is too tight and occurs > all the time so the other thread never gets time to do anything real. Your thread must have a valid working message pump to retrieve messages posted by PostThreadMessage. You your thread is suspended or sleeping or busy in a loop, the message pump is not working anymore and no message is processed. > My idea is now to slow down this tight loop just a tiny little bit so > that the other thread can do his work. I don't clearly understand where this tight loop is. Is it in the main thread, in the worker thread or somewhere else ? I any wase, you should never has loops. You must think asynchrnous with ICS and think asynchronous with your thread. The main thread and your worker thread should be blocked in their respective message loop (GetMessage or MsgWaitForMultipleObject). > I could do it via sleep Sleep is not good, at least at ICS side. Sleep will stop the thread. No message will be handled, no event will be processed. > or I could stop TWSocket's receiving for a short time. You can do that using TWSocet.Pause/Resume. For example if you detect your message list has too much messages not processed yet. This could occur when you have a fast network compared to the processing time you need. If you have complete asynchronous receive, the network may overflow your system if you don't stop receiving when you've got already too much data not processed yet. > Or I could change my protocol so that the next command may only > be sent after the receiver acknowledged the prior command. Most protocols are implemented that way. This has the good side effect of having the sender know when the receiver detected some problem in the data. Without ACK, the sender doesn't know his data has been processed properly. Implementing ACK may slow down overall operation. If you want to have a high performance thruput, you may want to implement a windowed protocol, that is allow the sender to send many commands without having received the ACK. The sender will stop sending more commands if no ACK is received for let's say 10 commands back (the number of pending commands is the window size). This kind of "windowed protocol" is not trivial to implement but offer high performance where thruput is high but round-trip is slow. > a) what would be better/best? It's up to you to know. I gave you the ideas. > b) what is the minimum time sleep can sleep (Win2K/XP) Sleep(0) will just give back the remaining of the time slice a thread has. He will get CPU back as soon as possible given his priority and all other threads running in the system. A time slice is something like 20mS. > c) how to pause and resume TWSocket and can there data be lost? There are two method Pause and Resume. No data can be lost, but when you call resume, you don't get any notification before the next packet, so maybe data is waiting in the buffer. You could call Receive to get it (returns <0 if no data available, if remote has closed or nb of bytes if any data was read). btw: I took the time to write this long answer because you are actively writing in the wiki. A kind of compensation for your work. Thanks. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
