EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TCP Transport Usage

Posted: 05/25/2010 20:10:08
by Tony Amos (Standard support level)
Joined: 02/26/2008
Posts: 4

I'd like some clarification on how to use the TCP Transport. I have a server application that runs as a Windows service. It receives messages from various clients on the network. After the server receives and processes a request, it gets the client's address, port, and queue name from the message envelope and sends a reply to the client.

I usually have multiple clients running on a single PC. I have to make sure the response gets to the right client, so I've considered 2 approaches:

1. Each client application uses a different port and the same queue name.
2. Each client application uses the same port and a different queue name.

Scenario 1 works, but I have to dynamically assign a port to each instance of the client application. It is possible to have dozens of clients running simultaneously on the same PC. This approach works, but port management creates a lot of overhead. So I tried scenario 2.

I have problems with scenario 2 when more than one instance of the client runs on the same PC. The clients send their messages to the server just fine, but the server only replies to the first client. The SendMessage from the server to each subsequent client throws a BadDestinationName or ConnectionFailed exception. I would prefer to use scenario 2 if possible since I can easily create unique queue names and eliminate the overhead of getting a valid TCP port for each client.

I will appreciate any useful advice, or alternative options.
Posted: 05/26/2010 11:17:02
by Eugene Mayevski (Team)

Issue #1 is that you retrieve client's address and port from the incoming message. This will work right until your client is behind a NAT or proxy or firewall. Then you get one of the following: (a) incorrect address/port and (b) blocked attempt to connect to the client.

Right approach would be

1) the client C connects to the server S and sends it's request
2) S replies "C, connect to me in a minute and send me token T for your request".
3) C waits a minute and sends request "is my request T ready?"
4) S either replies "get the results, here" or go to (2) above

As for your approach 2 (general information):

only one application can use the same port on the same computer at a time. So it must be dynamic port, yes. But as said, turning the client into the server in your scenario makes little sense.

Sincerely yours
Eugene Mayevski
Posted: 05/26/2010 12:46:03
by Tony Amos (Standard support level)
Joined: 02/26/2008
Posts: 4

Thank you for the guidance Eugene. That solution could work for me. As for #2 thanks for the reminder.
Posted: 06/17/2010 05:53:54
by David Perkins (Standard support level)
Joined: 12/03/2008
Posts: 17


Is that really how it must work for clients behind a NAT router?

I envisgaed that multiple clients (behinf a NAT) would connect to a server on the web and provided they maintained their connection via a keep-alive 'ping', the server could send messages to the clients at will. i.e. Most client requests will be synchronous, but some will be asynchronous, for which I want to avoid the client polling the server.

Is that not the case?
Posted: 06/17/2010 09:55:24
by Eugene Mayevski (Team)

MsgConnect is connectionless framework. It knows nothing about connections (socket transport has connections, but they are completely transparent to the rest of MsgConnect). So yes, the client needs to pull the server.

Sincerely yours
Eugene Mayevski



Topic viewed 7552 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!