rshields

When using socketserver, it's very important to decide early on what protocol to use. Since socketserver will pass along ANY message to ALL connected clients, it is a responsibility of the clients to interpret the message according to a defined protocol. So what is that protocol? Well, that's the beauty of socketserver; it's up to you to decide what the messages will look like. On this page I will present a few sample messages with a discussion of their protocols to assist you in defining your own system.

Let's take the most simple message; this one is used in the Processing sample:

   p

That's it; that's the entire message. The processing client looks at this message and realizes that a 'p' means it should raise the pen, and that means setting the drawing tool to noStroke(). If your entire system only had 2 types of clients this protocol would be perfectly acceptable. Type 1 (the user interface client) would pass along commands, and type 2 (the display client) would take action on those commands. You could have several user interfaces and several displays and action on any user interface would draw on all of the displays.

Another example of this protocol would be a shape definition, in this case a circle. The protocol could be defined as [x position],[y position],[diameter], resulting in something like this:

   129,317,44

This would tell a display client to draw a circle at 129, 317 with a diameter of 44.

The disadvantage to this protocol is that every broadcaster sends to every display. Let's look at another example of a protocol that tries to eliminate this potential problem:

   display1:129,317,44

The protocol has been changed to the following: [target display]:[x position],[y position],[diameter]. The display client would break apart this message, separating it at the ':', then looking at the first portion of the message, 'display1'. Now it can make a decision; am I 'display1'? If so, the circle should be drawn. Otherwise no action should be taken. By defining who the message is for, action can be limited to just the displays that we want to control.

Let's take this one step further. Here's another protocol: [target display]:[message source]:[x position],[y position],[diameter], like this:

   display2:interface1:129,317,44

With this protocol each user interface can send to any display, and the display can take appropriate action for a message from that interface. Maybe circles from display1 are red and circles from display2 are orange; with this protocol, that's an easy thing to do. This is my favorite protocol because it allows the addition of more clients that won't affect the operation of the ones already connected. Each client just needs to be aware of what its name is.

Is this a comprehensive list of the different types of protocols that socketserver can handle? Absolutely not! Although I'm breaking apart portions of messages with ':', that may be totally inappropriate for someone building an instant messaging system, since the users could send a message that contains a ':'. That's just a syntax difference; maybe there's a completely different way of letting the clients talk, a system in which each client takes turns. You still know who's talking, because they can start by saying who they are. The messages following that one would be what they want the other clients to hear, and then when they're done they could say something like 'pass'.

It was important to me when creating socketserver that I maintained this flexibility. It kind of complicates things because I can't just post a page saying 'here is the complete protocol for socketserver' because there isn't one. But after using socketserver for close to a year, I've found the ability to define my own protocol within clients to be incredibly useful, and I hope others do as well.

Think you've got a clever protocol system using socketserver? Please share with us all using the 'add new comment' link at the bottom of this page.