views:

1456

answers:

2

I have to maintain a single persistent socket connection to a payment gateway and use it to send financial messages and receive confirmation for the same. My application will be then used by various clients and so I need to devise a way to handle them concurrently and handle issues such as timeouts and retries etc.

Right now, my main issue is with accessing the socket... should I just lock the send and recv per message request and response or set up a queuing system and match them? I'll also be sending periodic echo messages on another thread.

Oh, and I am planning to do it in C#. I would appreciate some general advice on this issue.

+1  A: 

You need a persistent socket to the payment gateway, ok. By that I assume you mean it must stay connected.

Then you need to create a listener socket to listen for connections from your clients. Then act as a translator between the two.

I'm not sure I understand what you mean by "lock the socket". Lock it how?

Unless the protocol for the payment gateway is intended for multiple concurrent operations, you probably don't want to send more than one request at a time. This would mean a queue of some sort, or a thread for each request using some kind of mutex or semaphore to control access. A queue is more efficient in most cases.

Mystere Man
Locking the socket would mean to use some kind of synchronization technique (such as a monitor) to make sure, that one client can send its request and wait for the reply without other clients sending or receiving during that time. I think I prefer the queue though.
Smasher
+1  A: 

I did this exact thing (if I understand you correctly). I have a server that connects to some target devices over sockets and then clients hook up to the server to talk to different target systems. Is this (kind of) what you want? I have multiple clients talking to the same socket through the server.

In my server I keep a list of connected clients and a list of connected targets. When a client requests a target I add it to a matrix that is essentially a dictionary of connections because several clients can talk to one target at the same time. The server then pumps messages between clients and targets entirely asynchrounously and I use transaction IDs to keep track of the messages. So that when a target answers a request the server knows to which client to send the answer.

I'm not sure this is what you want but maybe what I did will help you a little on your way anyway. If I'm on the right track I can elaborate further.

Niklas Winde