Design Pattern for TCP communication

A

Anders Eriksson

I wonder if there is any Design Pattern for TCP communication
Application protocol?

My application is the client. The communication is messages (Questions
and Answers) plus a KeepAlive message that is sent every 12 seconds from
both parties.

Both the server and client can start a message(Question) but can't send
a new one before an answer is received.

When a party receives a message is must send a Acknowledge message. This
must be done before the other party respond to the message.
If an Acknowledge message isn't received within 10 seconds the message
must be sent again.

The KeepAlive message must be sent and answered even if we are in a
state of waiting for an answer to a question. Not sure how to act in
case of collision (i.e. that the KeepAlive is sent simultaneously as the
Question/Answer)

So there are two "workflows"
Question/Answer
KeepAlive

They should run in parallel.

Then we have the problem with connection or rather the lack of.
How handle that connection with the server is lost?

Hopefully I have described my problem sufficient so you can recommend a
solution!

// Anders
 
R

rbowman

Anders said:
The KeepAlive message must be sent and answered even if we are in a
state of waiting for an answer to a question. Not sure how to act in
case of collision (i.e. that the KeepAlive is sent simultaneously as the
Question/Answer)

I don't know if you have any flexibility in the protocol, but for most of
our interfaces the keep alive packet is sent only if there hasn't been an
exchange within the keep alive time. Also only one side sends the keep alive
message and the other responds.

There is also the condition where both sides initiate a question more or
less simultaeously. On a reconnect wold you want to send any pending answers
or just flush both sides and only send pending questions?

Do the questions need to be written to disk so a potential queue of
questions isn't lost if the process crashes?
 
A

Anders Eriksson

I don't know if you have any flexibility in the protocol, but for most of
our interfaces the keep alive packet is sent only if there hasn't been an
exchange within the keep alive time. Also only one side sends the keep alive
message and the other responds.
That is much better!
Nether I or the persons that program the server are experts on creating
a communications API, so we just took one "that we found" and edit it
until it worked for our purposes. Unfortunately it seems like the
original was not that good!

I will check with the server group and see if they have implemented the
KeepAlive.If not I will suggest that we use the way you describe.
There is also the condition where both sides initiate a question more or
less simultaeously. On a reconnect wold you want to send any pending answers
or just flush both sides and only send pending questions?
Good questions! In this particular project there isn't that many
different Questions and the work flow is pretty clear. The client always
initiates the communication.
Do the questions need to be written to disk so a potential queue of
questions isn't lost if the process crashes?
Well, that is something I have thought about! I must discuss this with
the project team.

Thank you very much for your input!

// Anders
 
A

Anders Eriksson

I don't know if you have any flexibility in the protocol, but for most of
our interfaces the keep alive packet is sent only if there hasn't been an
exchange within the keep alive time. Also only one side sends the keep alive
message and the other responds.
That is much better!
Nether I or the persons that program the server are experts on creating
a communications API, so we just took one "that we found" and edit it
until it worked for our purposes. Unfortunately it seems like the
original was not that good!

I will check with the server group and see if they have implemented the
KeepAlive.If not I will suggest that we use the way you describe.
There is also the condition where both sides initiate a question more or
less simultaeously. On a reconnect wold you want to send any pending answers
or just flush both sides and only send pending questions?
Good questions! In this particular project there isn't that many
different Questions and the work flow is pretty clear. The client always
initiates the communication.
Do the questions need to be written to disk so a potential queue of
questions isn't lost if the process crashes?
Well, that is something I have thought about! I must discuss this with
the project team.

Thank you very much for your input!

// Anders
 
R

rbowman

Anders said:
Good questions! In this particular project there isn't that many
different Questions and the work flow is pretty clear. The client always
initiates the communication.

That makes the design much easier. Many of the interfaces I do are queires
that are sent to a criminal justice information network. One query may
result in responses by several different agencies that are returned
asynchronously. There has to be a message id of some sort included with the
query that will be returned with each result so they can be correlated. One
immediate response simplifies the interface.

To make it even worse, the servers tend to be store and forward. If the
network has been down all the pending results are sent on the reconnect.

This may not be at all applicable to what you are doing but these things
tend to grow in complexity.
 
R

Richard Maher

I wonder if there is any Design Pattern for TCP communication
Application protocol?

My application is the client. The communication is messages (Questions
and Answers) plus a KeepAlive message that is sent every 12 seconds from
both parties.

Both the server and client can start a message(Question) but can't send
a new one before an answer is received.

When a party receives a message is must send a Acknowledge message. This
must be done before the other party respond to the message.
If an Acknowledge message isn't received within 10 seconds the message
must be sent again.

The KeepAlive message must be sent and answered even if we are in a
state of waiting for an answer to a question. Not sure how to act in
case of collision (i.e. that the KeepAlive is sent simultaneously as the
Question/Answer)

So there are two "workflows"
Question/Answer
KeepAlive

They should run in parallel.

Then we have the problem with connection or rather the lack of.
How handle that connection with the server is lost?

Hopefully I have described my problem sufficient so you can recommend a
solution!

// Anders

Just wondering what is the purpose of your keep-alives? Can yo not just
use setSocketOption(keepalive, true) to defeat the firewall rule?

You look to be catering for the restrictions of UDP but using TCP? Put a
timeout on your reads if you must but if it timesout then surely
something is wrong with the other end if he's meant to reply?
 
R

rbowman

Richard said:
Just wondering what is the purpose of your keep-alives? Can yo not just
use setSocketOption(keepalive, true) to defeat the firewall rule?

One thing it does is ensure the applications are at least minimally
functional. With the ort of interfaces I do there are periods, say 3AM in
the morning where there is no traffic at all. The keep alive or heartbeat
message demonstrates both the client and server are awake and ready to
answer the phone when there is actual traffic.
 
R

Richard Maher

One thing it does is ensure the applications are at least minimally
functional. With the ort of interfaces I do there are periods, say 3AM in
the morning where there is no traffic at all. The keep alive or heartbeat
message demonstrates both the client and server are awake and ready to
answer the phone when there is actual traffic.
But if the other end of the socket has gone away then any local i/o on
the socket with return and error.

ort?
 
R

rbowman

Richard said:
But if the other end of the socket has gone away then any local i/o on
the socket with return and error.

You're assuming the other end has gone away. An open socket connection does
not necessarily mean each end is listening and responding appropriately.
 
A

Anders Eriksson

But if the other end of the socket has gone away then any local i/o on
the socket with return and error.

ort?

there is a blog post here about Detection of Half-Open (Dropped)
Connections by Mr. Stephen Cleary, that clarifies why/when a keep-alive
is needed.
http://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html



Although this is very interesting and I'm realizing that my protocol
isn't "perfect" I would like to come back to my original question.

Is there a Design Pattern that would solve two parallel workflows?

// Anders
 
R

Richard Maher

there is a blog post here about Detection of Half-Open (Dropped)
Connections by Mr. Stephen Cleary, that clarifies why/when a keep-alive
is needed.
http://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html

"Since broken connections can only be detected by sending data, the
receiving side will wait forever."

Bollocks!
Although this is very interesting and I'm realizing that my protocol
isn't "perfect" I would like to come back to my original question.

Is there a Design Pattern that would solve two parallel workflows?

I suggest you stop reading crap on the net and try out some test cases.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

TCPClient 2
network design 6
WCF and duplex service contracts 1
TCP option Keepalive. 3
about using netrwork communication 1
Newbie: Design Pattern 6
reconnect tcp 3
Serial communication 4

Top