One additional note from me: If you use single ICS worker thread for the server, then you won't be able to utilize multiple CPU-cores. That's the same for client as well. To see how we cope with this problem on the client side, see the source of my WebStressTester at http://www.fastream.com/ics/Web%20Stress%20Tester%20SRC.zip
It's in BCB2006. Best Regards, SZ ----- Original Message ----- From: "Francois PIETTE" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Sunday, August 26, 2007 3:49 PM Subject: Re: [twsocket] Problems writing tester with connection counts >> However, TWSocketServer does not have what I need for these tests. I am >> not >> wanting to know concurrent or contiguous client connections. If I was, >> then >> yes, ClientCount would be sufficient. Rather, I am trying to determine >> how >> many connection lifecycles can occur over a period of time. This >> includes >> connect, build session (TWSOcketServer) and disconnect. > > As I understand, you are using a single connection to evaluate the time. > This will give a different time tahn if you used several parrallel > connections. You must be aware of that. This is because of low level > TCP/IP > protocol negociation which can take place in parallel for several > connections. So having many simultaneous connections result in an overall > better result. > > Setting up a TCP connection and gracefully closing a TCP connection are > processes which involve several packets to be exchanged between client and > server. There is a round trip time depending on the hardware and network > you > have. This is why having simultaneous connections will result in a better > global result. Depending on a lot of factors, establishing 10 or 100 > simultaneous connections mays take the same time as establishing only one. > Same for graceful close. > > What you do in your code between OnClientConnected and the graceful close, > and how you do it will drastically change the results. Fully understanding > how Windows handle messages will help interpreting the results. And if you > use simultaneous connections, using a thread for the processing of each > connection could change the numbers a lot (In both directions !). > >> This is not something that TWSocketServer will tell me. Ergo, my test is >> designed to determine this. > > Yes, TWSocketServer will tell you exactly the same thing as what you could > reinvent. TWSocketServer /is/ a TWSocket and instanciate a new TWSocket > for > each incomming connection. You can tell TWSocketServer to use your own > TWSocket derived class. You do as you like, but believe me, you are > reinventing the wheel. > > > -- > [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://www.elists.org/mailman/listinfo/twsocket > Visit our website at 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
