Need help on TCP communiction architecture. Patterns, books?

Question

Hi
I am currently developing a Java ME application that uses TCP for communication. Unfortunately the binary protocol I have to implement on the client is half-duplex whereas TCP is full-duplex. So I had to artificially limit and synchronize transmission and reception by using sync blocks, locks on mutex objects and message qureue decoupling. While implementing the protocol, step by step new cases appeared where I had to tweak the existing locking a bit. Now, the protocol seems to work (no stress/system test yes) but to be, the architecture is not as good as it could be and probably a bit fragile. For the next release/refactoring I'm looking for a better way to solve the problem.
There are different possible message flows:
- Client transmits, Server sends ACK
- Clients is Idle, Server requests data, Clients sends ACK, Client sends response, server sends ACK
- Exceptions must be handled: Reception timeout, bad packet format etc. Then the packets must be resent...
Right now, I have a main thread that will use a queue to store messages. When transmission starts, it will send messages. If it fails, it will roll back the queue and send again. Then it waits on a queue for the ACK using a timeout. There is a second thread that is used for reception. It waits on a blocking inputstream read, parses the messages and puts them into a reception queue.
In this current architecture, there are some problems: When receiving data, sometimes I have to already handle and interpret the packets right now without storing it into a queue because because I need to send an ACK immediately which again depends on the outcome of the handler. But this could mess up a ongoing transmission/reception so I have to sych it by using a flow control mutex object of which I don't think it's a good way. A second problem is, that when I'm sending the response messages to a server request, the reception thread is locked because the response sending is already called by the reception thread itself and I'm deep down in the call stack. My work-around is to start a new thread to transmit the packets and wait for an ack so the reception thread can go on receiving the ack.
But I don't have a good feeling about this.
Is there anyone with a good approach or any hints on books or patterns about this? I bet there must be other people before me having the same problems... :)
Thanks a lot!
/Jan

Answer 1

stelzbock wrote:
Hi, thank you all for the valuable comments. I try to get to a bookstore to get a deeper look into that book because it's unix and I don't have anything to do with any NIX OSes. But probably I could use some of the general archticture ideas.
jschell wrote:
You have a protocol and messages.
The protocol layer handles the send/receive the message layer handles what messages to send and expected responses.
Hmm, interesting, is the message layer higher than the protocol layer? I mean, what tasks do the message layer cover?
Yes. Specifics depend on details of the actual specification.
The message layer might use three methods provided by the protocol layer.
- Send request and receive response
- Send request
- Receive response.
The message layer constructs the message while the protocol layer handles the CRC (as an example.)
I need to send an ACK immediately which again depends on the outcome of the handler.I would like to think that you are mis-interpreting that.
Normally something like that would be something like the following
- Get the message
- Verify the CRC
- Send the ACK if the CRC is valid.
In a case like that it is still part othe protocol rather than the message flow.generally, I would agree. But what I am doing is an extremely resource optimized embedded protocol that runs via TCP but could also be RS232 or CAN or anything else. It's packet header contains only 3bytes and the protocol supports dedicated messages that are used for instance to set a configuration item on a remote device. In this case, the message content must be parsed and interpreted before sending an ACK because in this case, the ACK acknowledges not only the header but the payload as well.Still depends on the specifics.
But then the ACK is a response and nothing more. At the message level you can sequence it as
- Hold protocol (method provided by protocol that dedicates socket to this flow)
- Send request and receive response
- process request
- Send Ack response (protocol layer can actually encapsulate ACK or message layer can do it.)
- Release protocol (releases the socket.)