NetSimple Client sending multiple packets on a thread

[Paul Blais]

I have a NetSimple client on a thread that gets a Notify to send a SysyID of a data record. Once I have done the Send how can I know when I can open a new connection and send another record.

It comes down to will a Notify come in during the period after I open the previous connection but before the send. I can set a blocking flag between the open method and the send method and buffer the requests to a queue. So I am fine between the open and send. Can I open a new connection right after I do the Send or do I need to watch for something else on a timer to know when the next open can be called.

During this period between open and send will Notify events be able to post? I assume while waiting for the connection to open they can but once I trap the open connection and start the send it can't. This leaves the post send period in question.

Since the IP and Port are the same it seems launching a new thread for each transmission won't solve the problem but would stack up the port opens. Would that be true?

[Bruce]

Hi Paul,

>> Once I have done the Send how can I know when I can open a new connection and send another record.

Presuming of course that the remote server neither sends you an acknowledge nor closes the connection, the good news is
"immediately". The Close request will done, but the connection won't actually close until all the data waiting to be sent has been sent.

That said, the server on the other end may handle the close badly. The server _should_ still feed you the incoming packet (even after the close) but it's possible that it doesn't.

the Open is asyncronous so you can do an "open" after the close, and when it's all ready it'll let you know.

An alternative of course is the "Multi-Client" class which lets one client opene multiple connections to potentially different servers at the same time.

cheers
Bruce

[Paul Blais]

MultiClient won't help in this one case as the client target is always the same for this thread - same IP and same port. Muklticlient isn't that needed because we don't internally do very much processing just mostly a "trucking company" moving data as freight. This one instance is a VLAN connection with both a server and a client. Others may be HTTPS or just TCPIP. This client sends requests and our sever on another thread gets the responses because the service can't be done in real time. It takes people to do a service and send the results. They do send status messages that are tracked with a unique ID.

So based on what you said I have a threaded queue of record numbers I want to send. This queue is populated via NOTIFY. A Timer will call the routine for making the next send request and when called will set a block flag so it won't be called again until the open is connected AND the send has been sent. The code after the send will clear the flag and the next EVENT:Timer will stage the next one. The open will perhaps have to wait if it is done sending the last one but the blocking flag will be set at the routine start so that any NOTIFY events will be added to the queue for later processing. Sooner or later the queue will be empty (i hope).

If a send fails I don't need to worry as the server thread won't get a return message. That thread will Set the sent bit in the data record on disk so we know it was sent and received. We still don't have the service results yet as they come back on the server thread when they get around to it and that might be a day or two.

I'm doing a lot of this type of tossing a package over the fence and sending it some place. Internally we send things inside our own network that may be located in more than one data center and with those transmissions we get a response with every send. We hope to have a half dozen providers so we can bundle these services as one service.