views:

1043

answers:

8

I have an existing standalone application which is going to be extended by a 3rd-party, using a network protocol. The capabilities are already implemented, all I need is to expose them to the outside.

Assuming the transport protocol is already chosen (UDP), are there any resources that will help me to design my application protocol?

There seems to be a lot of information about software design, but not on protocol design. I've already looked at Application Protocol Design.

+2  A: 

First off, UDP is primarily a one-way broadcast transport method. Also, it is potentially lossy, so you need to be able handle missing packets and out-of-order packets. If you need any level of reliability from UDP, or require two-way connections, you will end up needing just about everything from TCP, so you might as well go with that to start with and let the network stack take care of it.

Next up, if your data is potentially larger than a single IP packet then you will need some way of identifying the start and end of each packet, and a means of handling illegal or corrupt packets. I would recommend some kind of header with packet length, some kind of footer, and maybe a checksum.

Then you need some way of encoding the messages and responses. There are many RPC protocols around. You could look at SOAP, or design a custom XML-based protocol, or a binary one.

Anthony Williams
It would probably be preferable to use unreliable to lossy. Just to nitpick :D
mdec
UDP is not only lossy but can also deliver packets out of order. This is nasty.
Rafał Dowgird
why do you need a footer, when u have the length field in the header
Vivek Sharma
Technically, if you are using UDP you don't need to identify start and end of a packet, that is handled by the IP layer (allowing up to 65K per packet). Same thing for corruption, the IP layer checksum should be able to catch this.
Kevin Nisbet
A: 

If you do not want to build your protocol from ground up, you should take a look at SOAP. Support varies for different programming languages, but cross language communication is explicitly encouraged.

Unfortunately UDP and SOAP seem to have stuck in its infancy, HTTP is most commonly used.

GrGr
A: 

If you're choosing XML keep in mind that you will have a giant overhead of markup.

A simple binary protocol will also be need not so much ressources to parse compared to xml.

echox
+3  A: 

Did you looked at:Google Protocol Buffer? It seems a good way to resolve this issue.

You can create an endpoint that communicates with you existing app and then respond from 'outside' using the protobuffer protocol. It's binary, so it's tiny and fast and you don't have to write your own protocol manager, 'cause you can use the Google ones. The downside is that it have to be implemented on both sides of the system (on your 'server' side and on the consumer/client side).

ezu
Note that the RPC standard(s) isn't (aren't) all that fully formed yet.
Marc Gravell
A: 

I have an existing standalone application which is going to be extended by a 3rd-party, using a network protocol.

It would help to know a little more about what your program does and what the nature of these 3rd party extensions are. Maybe some rationale for using UDP?

A: 

Another recommendation for protocol buffers - nice tight binary with little effort. Note, however, that while the binary protocol is well defined, there isn't yet an agreed RPC standard (several are in progress, tending to lean towards TCP or HTTP).

The spec makes it very easy to have the client and server in different architectures, which is good - plus it is extensible.

Caveat: I'm the author of one of the .NET versions, so I may well be biased ;-p

Marc Gravell
+1  A: 

See Jabber protocols design guidelines and RFC 4101. Although it is aimed at making RFCs more easy to understand to reviewers, this RFC provides some interesting advices.

philippe
A: 

You should really think hard about whether you really want to design, document and maintain your own protocol or use something that is already existing. It is probable there is already a documented protocol that matches your needs. Depending on what you are doing it will probably look overkill at first and implementing all the spec will look tedious and a lot less fun than writing your own but if you intend for your application to still be actively developed in a few years it should save you a lot of time and money to use something that already exist and is known by third parties. Besides, if you can use an existing library for that protocol, the implementation part should be a lot faster.

Designing new protocol is more fun than implementing one but less than maintaining one as you have to live with all the defects. No protocol is perfect but if you have never designed one you can be assured you will make more mistake designing it than the people who designed the existing well known protocol you could use instead.

In short, leverage what already exists whenever possible.

Krunch