Hello, again, Francois. Thanks for the additional input. Please forgive me, I don't mean to be pesty, but I am confused by how I could be reinventing the wheel?!?!
Obviously, the challenge with exchanging information via this email format is that I am quite limited as to the scope of detail I can provide. I think the confusion is that I am trying to explain what I am doing in an abbreviated form, which makes it hard to communicate the actual details of the issue. Let me clarify a few things: > As I understand, you are using a single connection to evaluate the time. Actually, the client tester is designed to be run simultaneously on multiple machines, as well as multiple instances on one machine. Yes, this version is single threaded itself and uses one connection. But, obviously, aggregating concurrent connections for a more appropriate result is the goal. I am simply using one single client as a base testing core, but am able to run multiple clients concurrently. This allows me to see the actual and effective performance points in response to seperate client streams on the same CPU, different host, etc. Additionally, just to make sure I am clear, I am not evaluating "the time", but rather various types of lifecycles over a period of time. > 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. Therein lies the rub. I do get how messages work in Windows; I have been coding in them back to the Borland C++ OWL framework. That is why I was confused as to why the TWSocket internal messages would own the app's thread manager like it is in my tester, especially when I am not calling ProcessMessages. The test code uses out-of-line messages to prevent this very problem. Inserting ProcessMessages is not a fix, but a test of the symptom. My lack of understanding lies in the TWSocket internals, not in Windows messaging, albeit I imagine that I do not have the grasp of it that you do... :) > And if you use simultaneous connections, using a thread for the processing of each > connection could change the numbers a lot (In both directions !) I agree. The server is built in two modes: One uses a managed thread pool for packet handling, the other uses a single threaded packet handler. By packet, I mean my transport packetizing entities, not IP units. Additionally, the client can be built in either of these two modes as well. These will allow me to compare threaded vs. inline processing. When I ran into this problem, I built both as single threaded handlers, so that I can remove the threading logic from the equation. > You do as you like, but believe me, you are reinventing the wheel. The ClientCount property that you are referring to simply returns the number of concurrent connections and has no cummulative bearing over time. I am confused by your recommendation to use the ClientCount property to determine any of the metrics I am looking for. Perhaps, I am greatly confused, which I guess is possible. But, given your component pattern, I do not see the relevance of this property for my test. I have been building TCP/IP apps for quite a number of years, as well as using your great components for years as well, so I don't think I am a complete newbie. However, I definitely do not want to reinvent the wheel, but I was simply stumped by the simplicity of what I was doing and why I was having a problem with it. I am sure the problem lies in my code, not ICS. Anyway, thanks for the input. Perhaps this explains what I am doing more clearly. I did not mean to take so much of your time or generate so many emails. I was hoping there was a quick, short, illuminating answer to my delimma. I will figure this out. Thanks... Hoby -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Francois PIETTE Sent: Sunday, August 26, 2007 7:49 AM To: ICS support mailing 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
