Design Pattern for TCP communication

  • Thread starter Thread starter Anders Eriksson
  • Start date Start date
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
 
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)
Click to expand...

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?
 
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.
Click to expand...
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?
Click to expand...
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?
Click to expand...
Well, that is something I have thought about! I must discuss this with
the project team.

Thank you very much for your input!

// Anders
 
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.
Click to expand...
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?
Click to expand...
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?
Click to expand...
Well, that is something I have thought about! I must discuss this with
the project team.

Thank you very much for your input!

// Anders
 
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.
Click to expand...

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.
 
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
Click to expand...

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?
 
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?
Click to expand...

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.
 
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.
Click to expand...
But if the other end of the socket has gone away then any local i/o on
the socket with return and error.

ort?
 
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.
Click to expand...

You're assuming the other end has gone away. An open socket connection does
not necessarily mean each end is listening and responding appropriately.
 
But if the other end of the socket has gone away then any local i/o on
the socket with return and error.

ort?
Click to expand...

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
 
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
Click to expand...

"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?
Click to expand...

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