You need a form of serialization," or "marshalling."

Built-in functions to do this in most Java, C# and similar libraries aren't very efficient (they encode type information, versioning, and other unnecessary-for-games data.)

There are various articles (mostly in C++, some in C#) about this on my blog: http://www.enchantedage.com/taxonomy/term/17

Typically, you send more than one message in a single UDP datagram.
Typically, you define your message format as something like:
<type> <length> <... data ...>
One byte each for "type" and "length" gets you pretty far.

Thus, your actual UDP datagram would look like:

<type> <length> <data * length> <type> <length> <data * length> ...


This allows you to figure out what each message is, and how long it is (so you can find the next message.)

The header typically will contain an application-specific identifier, serial number (for de-duplication, etc) and perhaps server time information and maybe a checksum, if you don't trust the pretty dumb UDP checksum algorithm, or want to do cryptographic signatures or whatever.

For example, here's one possible format:

<id0> <id1> <serial> <acklast> <ackseq> <timebyte>

id0 and id1 are bytes that you choose, that mean that you can tell your packets apart from random packets that some application might send on your particular port. (This is most important for broadcast, but useful for regular UDP as well)
"serial" is simply incremented by 1 for each UDP packet sent by the sender, and wraps around from 255 to 0.
"acklast" is the serial number of the last packet received from the other end, used for knowing which packets made it. <ackseq> is how many packets before <acklast> were received without any drops, capped at 255.
Note that this does not allow you to positively identify packet sequence numbers that were NOT received, but you typically don't need that.
Finally, "timebyte" is perhaps something like the current server clock in units of ten milliseconds, again wrapping around from 255 to 0. This can be used for clock synchronization, etc.

I've use variable width encoding for bitpacking size types. for example use the first 7 bits of a byte for size, and if the number is greater than 127, encode the rest of that number into another byte, and so on.

There are many ways to read/write data into a packet. In any case, it will almost always be based around a serialisation / deserialisation layer that encode/decode your objects properties into bitstreams / bytestreams, which are then passed to the transport layer to be sent off.

Simply dumping raw objects into packets is highly inefficient, does not provide scope for error checking (value range, value types, versioning, ...), object aggregation (basically, objects containing pointers), and does not support cross-platform communications (which isn't a big deal, but for the sake of completion...).

would look something like this


struct data
{
char nickname[20];
char text[255];

virtual bool serialise(bistream& out) const
{
bool ok = out.write_string(nickname, sizeof(nickname));
ok = ok && out.write_string(text, sizeof(text));
return ok;
}
virtual bool deserialise(const bistream& in)
{
bool ok = in.read_string(nickname, sizeof(nickname));
ok = ok && in.read_string(text, sizeof(text));
return ok;
}
};


Then transmitting your packet to all clients in the game could look like...

socket.broacast_packet(out.begin(), out.size());


stuff like that. Really look up some serialisation as it's really handy for what you want to do.