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
Re: [twsocket] Problems writing tester with connection counts
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
Re: [twsocket] Problems writing tester with connection counts
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
Re: [twsocket] Problems writing tester with connection counts
Thanks much. I will look through it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Fastream Technologies Sent: Sunday, August 26, 2007 7:54 AM To: ICS support mailing Subject: Re: [twsocket] Problems writing tester with connection counts 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 -- 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
[twsocket] Problems writing tester with connection counts
Hello... I am really stumped. I am attempting to write some testing applications that will test the performance of some TCP/IP transport components that I have written. My components use TWSocket components for the TCP/IP interface and implement an encrypted, packetizing stream over TCP/IP. The test is real simple. I am just trying to see how many connections per second I can make with the components. The problem is that the server and the client report different results for the number of connections and I CAN NOT figure out why?!?!?! I think the problem is my approach to writing the test applications, but I can't figure what where the problem is?!?!? Basically, there are two testing applications, one is a server and one is client. The test is just to see how many connections (sessions) can be generated during a given period, e.g. per second. The test is really simple, actually, which is what is stumping me. The Server works this way: 1. The server starts and immediately enters listening on a port. 2. Whenever the server receives a client connection, I increment a connect count. I do this in the Server's OnClientConnect event. 3. Whenever the server receives a client disconnect, I increment a disconnect count. I do this in the Server's OnClientDisconnect event. That is it for the server, other than a few minor functions, like letting the user manually clear the counts via a button on the form. The Client works this way: 1. The user sets a few controls (length of test, port, etc). 2. The user starts the start via a button. 3. A test flag is set and a system timer is started. 4. The Client initiates a connection to the server. 5. When the client gets a connection, I increment a connect counter and close the connection. I do this in the OnSessionConnected event. I close the connection by posting a message to my main form, which in turn closes the connection. This way, I don't close the connection from the Client Socket's message handler. 6. In the Client's OnSessionClosed event, I check to see if the test has finished. The test is finished when the timer has fired and a flag is cleared. If it has not finished, then I initiate another connection to the server. I do this by posting a message to the main form, which in turn starts the connection, so that I don't start the connection it in the Client Socket's message handler. There are two problems with this: 1. The count of connections on the server and the count of connections on the client will sometimes be off by a few. Not always, but most of the time. The first test will usually be same, say 128 on both ends. But, subsequent tests will be off by two or three, like server = 131 and client = 129. I do not understand this. Is this just an inherent problem with windows socket messages and how I have implemented the test? Perhaps, there are pending messages in the socket que that haven't been processed or something? I am concerned that I am missing an event or something. 2. Even though I use local messages to start and stop the connections, the Client application will not process any other messages unless I call Application.Processmessages, which I call in the OnSessionConnected event. If I do not call ProcessMessages, the timer event never fires and the test just runs forever or until I close the Server, then the Client application processes messages and stops the test. If I am doing the connects and disconnects using posted messages to the form, then why don't other messages get processed as well? Why is it looping in the TWSocket event handlers only? That is rather odd. I hope this makes sense. Is there a better way to implement this test? Do I just not understand the windows socket message handling enough to understand why this isn't working? I am tempted to just ignore the difference in counts, but I am concerned that there is an underlying flaw in how I am using the TWSocket components and I am concerned that I have a bug that I am not aware of in my components. Any input would be appreciated. Thanks much. Hoby -- 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
Re: [twsocket] Problems writing tester with connection counts
2. Even though I use local messages to start and stop the connections, the Client application will not process any other messages unless I call Application.Processmessages, which I call in the OnSessionConnected event. That is probably your problem. NEVER call ProcessMessages or any other form of the message pump from an event handler. You'll have events re-entered and this is generally very bad (even with a simple TButton !). btw: Use TWSocketServer for your server program. It already has most of what you need, for example ClientCount. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Hoby Smith [EMAIL PROTECTED] To: twsocket@elists.org Sent: Saturday, August 25, 2007 3:04 PM Subject: [twsocket] Problems writing tester with connection counts Hello... I am really stumped. I am attempting to write some testing applications that will test the performance of some TCP/IP transport components that I have written. My components use TWSocket components for the TCP/IP interface and implement an encrypted, packetizing stream over TCP/IP. The test is real simple. I am just trying to see how many connections per second I can make with the components. The problem is that the server and the client report different results for the number of connections and I CAN NOT figure out why?!?!?! I think the problem is my approach to writing the test applications, but I can't figure what where the problem is?!?!? Basically, there are two testing applications, one is a server and one is client. The test is just to see how many connections (sessions) can be generated during a given period, e.g. per second. The test is really simple, actually, which is what is stumping me. The Server works this way: 1. The server starts and immediately enters listening on a port. 2. Whenever the server receives a client connection, I increment a connect count. I do this in the Server's OnClientConnect event. 3. Whenever the server receives a client disconnect, I increment a disconnect count. I do this in the Server's OnClientDisconnect event. That is it for the server, other than a few minor functions, like letting the user manually clear the counts via a button on the form. The Client works this way: 1. The user sets a few controls (length of test, port, etc). 2. The user starts the start via a button. 3. A test flag is set and a system timer is started. 4. The Client initiates a connection to the server. 5. When the client gets a connection, I increment a connect counter and close the connection. I do this in the OnSessionConnected event. I close the connection by posting a message to my main form, which in turn closes the connection. This way, I don't close the connection from the Client Socket's message handler. 6. In the Client's OnSessionClosed event, I check to see if the test has finished. The test is finished when the timer has fired and a flag is cleared. If it has not finished, then I initiate another connection to the server. I do this by posting a message to the main form, which in turn starts the connection, so that I don't start the connection it in the Client Socket's message handler. There are two problems with this: 1. The count of connections on the server and the count of connections on the client will sometimes be off by a few. Not always, but most of the time. The first test will usually be same, say 128 on both ends. But, subsequent tests will be off by two or three, like server = 131 and client = 129. I do not understand this. Is this just an inherent problem with windows socket messages and how I have implemented the test? Perhaps, there are pending messages in the socket que that haven't been processed or something? I am concerned that I am missing an event or something. 2. Even though I use local messages to start and stop the connections, the Client application will not process any other messages unless I call Application.Processmessages, which I call in the OnSessionConnected event. If I do not call ProcessMessages, the timer event never fires and the test just runs forever or until I close the Server, then the Client application processes messages and stops the test. If I am doing the connects and disconnects using posted messages to the form, then why don't other messages get processed as well? Why is it looping in the TWSocket event handlers only? That is rather odd. I hope this makes sense. Is there a better way to implement this test? Do I just not understand the windows socket message handling enough to understand why this isn't working? I am tempted to just ignore the difference in counts, but I am concerned that there is an underlying flaw in how I am using the TWSocket components and I am concerned that I have a bug that I am not aware of in my
