>> You will need to invent or borrow a protocol -- a way to group the bytes
>> together into messages and decide what they mean. (That's for TCP; I believe
>> UDP works the same way but I haven't used it myself.)
>
> How do you create a protocol?
It sounds much scarier than it is. It's like reading from a file that
somebody might be appending to at the same time -- you have to do it in
pieces, and be prepared to wait for the writer sometimes.
A protocol is nothing more than the format of the message. It can be as
simple as you want it to be. The sender constructs the message according to
these rules, and the receiver interprets it according to the same rules.
For example, in a TCP-based network game I wrote, I use this simple, generic
protocol for my messages:
<type>content</type>
The message content is surrounded by starting and ending tags, which contain
the message's type. (Since I control all message content, I can guarantee
the '<' and '>' characters will never occur inside a type or content
string.) Here is an example of a message that I might send using this
protocol:
<gameInfo>players=2;shipsPerPlayer=4;boardSize=11</gameInfo>
Now imagine that you have a couple of TCP sockets exchanging data. Most of
the time, for short messages like the one above, the whole thing will get
sent in one chunk. But once in a while, or if your messages get long, it
will get split up. Perhaps the underlying network facilities are busy, or
they can't handle a message as long as you want to send. The TCP socket
hides all those details from you, but since it doesn't know anything about
the format of your message, it can't tell you when one starts and another
one begins. It does, however, keep all the chunks in the proper order.
So while my sending socket can just write its data out in a single burst, my
listening socket has to be a little smarter. Whenever it gets a "data
available" event, it scans its buffer for the '<' character. When it finds
one, it then looks for the '>' character and whatever is between the two
constitutes the message type.
It then looks for that same type surrounded by '</' and '>', and if it finds
that, it knows it has a complete message, It removes the message from its
buffer and calls a message processing routine with the type and content as
parameters. The message processor simply looks at the type and interprets
the content based on that.*
If at any point the scan doesn't find what it's looking for, that just means
the buffer doesn't contain a complete message yet. In that case, the scan
exits, and the system waits for the next chunk of data to become available,
at which point it tries another scan.
(*Actually, for easier re-use, I wrapped all the scanning into a class I
call a "TagPipe", which has a GotMessage event that gets called with the
type and message parameters. My game window has a TagPipe property, and a
message processor method that is called by the GotMessage event.)
lj
---
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
|