I'm trying to connect a supervisor to an application using their custom protocol over TCP. The communication format I'm dealing with has commands like '123HELLO', to which the supervisor responds with '123HELLO@somedata'. The first three digits are a correlation ID, followed by the command and then some variable-length data. The tricky part is that the data doesn't indicate its length and lacks any final delimiter to signal when it ends. I've been told by the team behind the protocol that responses come in one packet, but that doesn't seem reliable. Right now, I have to open a new TCP channel for each request and wait to ensure I get the full response before closing it. This isn't optimal, as I want to send multiple commands at once. Am I correct in thinking there's a flaw in their protocol, and if so, how should I communicate this to them? Or could I be misunderstanding something about how TCP works?
5 Answers
This is a poor way to design an API. You might be lacking experience, but it seems like they’re the ones missing the mark here. Advocate for better practices since working with such a faulty setup is only going to lead to more trouble down the line.
You're on the right track thinking that their protocol has a flaw. You might want to gather more information on how data is sent and received in their setup. Perhaps if you can find out whether responses for multiple commands come back separately, you can leverage that correlation ID to determine where one response ends and the next begins. Create diagrams that show your understanding so they can see where the gaps are.
It sounds like you're treating TCP like a packet-based protocol, but TCP is a stream protocol. Essentially, it sends data without boundaries, which means you have to handle the separation of messages yourself. The team should really be providing a way to know the end of a message, like including a length prefix or a terminator. Otherwise, it could become a real mess when the responses start overlapping or the data doesn't fit in one packet.
Exactly! If they insist it's always in one packet, run a test where you send a command that will definitely exceed the packet size. That should illustrate the issue. You can then suggest a change to their protocol based on your findings.
You could also suggest a simple protocol upgrade, like moving to a format that includes a character to signal the end of a message, or even just a fixed length for each message. They might be more open to that than a complete overhaul.
Honestly, relying on their API as is seems like a recipe for headaches. If there's no clear method of determining message boundaries, it's just bad design. You should encourage them to implement industry standards, which would make everything cleaner and easier for everyone involved. Just let them know that what they're doing isn't standard practice.
And don't underestimate the power of visual aids! Sometimes a diagram can clarify complexities that words cannot. Use that in your discussions with them.