This discussion is archived
5 Replies Latest reply: Jul 27, 2010 2:40 AM by 843853 RSS

Need help on TCP communiction architecture. Patterns, books?

843853 Newbie
Currently Being Moderated
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
  • 1. Re: Need help on TCP communiction architecture. Patterns, books?
    800387 Newbie
    Currently Being Moderated
    AFAIK, this is still the Bible for networking. Three volumes. Here's a link at Amazon.

    - Saish
  • 2. Re: Need help on TCP communiction architecture. Patterns, books?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    stelzbock wrote:
    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... :)
    You have a protocol and messages.

    The protocol layer handles the send/receive the message layer handles what messages to send and expected responses.
    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.
  • 3. Re: Need help on TCP communiction architecture. Patterns, books?
    843853 Newbie
    Currently Being Moderated
    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?
    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.

    I also think its not best approach, but I have to deal with it.
  • 4. Re: Need help on TCP communiction architecture. Patterns, books?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    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.)
  • 5. Re: Need help on TCP communiction architecture. Patterns, books?
    843853 Newbie
    Currently Being Moderated
    Hi,

    thanks for your valuable comments!

    I actually have split the previous protocol implementation into two layers: the protocol and the transaction layer. The protocol handles incoming packets by a thread and puts them into a queue and is able to send messages using the given transport implementation.
    The transaction layer has a separate thread that mangages the flow control. It only allows reception or transmission at a time. It has two additional classes: Reception and Transmission. A Reception object is created whenever a payload packet from the server is received and will be completed when the termination packet is send. A Transmission object is created whenever the higher layer wants to send messages and is destroyed when all messages have been acked by the server. In both cases, the classes with hold the protocol and release it afterwards as you suggested.The whole thing is a little bit more complex than I have explained here, but the architecture is surprisingly stable. I ran all the tests from the previous implementation and passed them without any problems.

    Thanks a lot!