[ENet-discuss] A query about channels

M. Rijks enet at forge.dds.nl
Sun Jan 17 14:22:33 PST 2010


Note to self: don't ask questions that can be researched. Turns out  
that structs cannot be iterated over, let alone determining the type  
of a field at such an index. Will take a little more effort to  
serialize structs, but I still think it's the preferred method.

Quoting "M. Rijks" <enet at forge.dds.nl>:

> Isn't it better to serialize the struct somehow? There are a few
> reasons I'd do this:
>
> 1. Structs can't contain strings (or other data types) that have
> arbitrary length, and maxing them out towards some convenient maximum
> is expensive in terms of message size.
> 2. You can remain forward/backward compatibility of structs between
> versions of your games, by ignoring missing or unknown data.
> 3. You do not have to send all struct data if you don't need to.
>
> A practical example is a session information message - I'd like it to
> contain - or not - a session ID, sesion name, session owner name,
> maximum amount of players, current amount of players, map data, session
> settings, et cetera. But not necessarily all.
>
> I'm not at home in C++ far enough to know if struct fields can be
> accessed by index somehow, but it would be easy to decompose a message
> - one byte to identify the struct, followed by a stream of fields each
> started with the index of the field in the struct (assuming 255 members
> max) by which you can look up its size in the struct, and then know how
> many bytes this field should take from the message.
>
> Would really make it easy to serialize just about any struct. Speaking
> of which, when receiving any kind of struct (serialized or not) it does
> seem to make sense to check the incoming struct size and see if it
> matches your own, or you may crash your server. I'm thinking about
> malevolent players intercepting packages, changing the size and then
> reapplying the CRC to pass it under ENet's radar.
>
>
> Quoting Jay Sprenkle <jsprenkle at gmail.com>:
>
>> A great way to do this. There are plenty of other ways. Just identify the
>> data in any way you like so you can classify it on the receiver.
>>
>> 2010/1/17 Thorbjørn Lindeijer <bjorn at lindeijer.nl>
>>
>>> On Sun, Jan 17, 2010 at 19:50, Alex Milstead <alex.milstead at gatech.edu>
>>> wrote:
>>>> Also, Jay you mentioned earlier that it was easy to do simple data-type
>>>> checking on the receiving end. I'm a bit of a fledgling network
>>> programmer
>>>> -- I'm still definitely becoming more acquainted the vast amount of
>>>> unfamiliar programming techniques in this particular arena. The only
>>>> surefire type-checking system I know about in programming is in java
>>> (=/),
>>>> with it's "instanceof" operator. As far as I know this type of mechanism,
>>> or
>>>> anything similar, doesn't really exist in C/C++. So my next question is,
>>> if
>>>> we're sending binary data along and receiving it as binary data, what's
>>> the
>>>> most efficient way of type-checking the probable struct being piped
>>> through?
>>>
>>> You give it a number which designates its type. You'd usually prepend
>>> such a number to each of your messages, so that you know how to
>>> interpret them on the other end.
>>>
>>>
>> Cause united breaks guitars
>> http://www.youtube.com/watch?v=5YGc4zOqozo
>>
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss





More information about the ENet-discuss mailing list