[ENet-discuss] A query about channels

[Nuno Silva]

I prefer my approach. It's simple yet effective. Sure, you dont have a
structure to hold you data nice and warm, but it's simple enough.

One note to you guys, just in case: Considering a game might have a *lot* of
packets, split the packets by group, with a file per group, or more if
needed.
E.g., my game is very incomplete and i already have about 20 packets and my
ProcessPacket function already has over 2k lines of code. What i will do
soon is split the packet by groups (client validation, login, etc), with a
file for each group, with a function to process each group. That way my
ProcessPacket function will only have to do some basic if comparisons to the
ID it gets and run the function appropriate for that ID.

On Sun, Jan 17, 2010 at 8:25 PM, Alex Milstead <alex.milstead at gatech.edu>wrote:

> I'd kicked around the idea of using some sort of required "cmd" field as
> the first field in the struct being sent, my only concern is what happens to
> the rest of the "trash" data after first memcpy. E.g., StructA and StructB,
> StructB is bigger than StructA, both have the first field as a "char cmd",
> but the rest of the data causes the structs to not be the same size. If I
> send a StructB but memcpy the incoming binary data into a StructA to check
> the command type, is it safe to then re-memcpy this incoming data back into
> a StructB once I've figured out the command type? Or is there weird memory
> stuff that happens (I would assume not as the incoming data will always be
> the same, we can copy that to whomever we wish at will)?
>
> Also, a packet class wrapper sounds like a great idea! Thanks for the
> suggestions.
>
>
> On 1/17/2010 3:06 PM, Ruud van Gaal wrote:
>
>> I use a packet class where I can just add bytes&  shorts&  ints (and
>> strings) to a packet. So you just:
>>
>> enum Cmd
>> {
>>   CMD_CAR_UPDATE,
>>   CMD_CHAT,
>> ...
>> };
>>
>> pkt=new Packet();
>> pkt->AddChar(CMD_CAR_UPDATE);
>> pkt->AddFloat(carX);
>> ...
>>
>> and later at the receiving end:
>>
>> cmd=pkt->GetChar();
>> if(cmd==...){ ... }
>>
>> Although a struct where all things start with 'char cmd' can also do
>> nicely.
>> Learn more about pointers and dereferencing them in C/C++.
>>
>> Cheers,
>> Ruud
>>
>>
>>
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: enet-discuss-bounces at cubik.org
>>> [mailto:enet-discuss-bounces at cubik.org] Namens Alex Milstead
>>> Verzonden: Sunday, January 17, 2010 20:54
>>> Aan: Discussion of the ENet library
>>> Onderwerp: Re: [ENet-discuss] A query about channels
>>>
>>> In that case, is there a solid way to extract that
>>> identifier? Or will I need to do some I'm aware of sprintf
>>> calls, is it common practice to simply "sprintf" the first
>>> integer of the received binary data into a buffer and
>>> (effectively) switch-case on that buffer, then memcpy the
>>> remaining data that follows? Or is there a better way of doing this?
>>>
>>> Cheers,
>>> Alex
>>>
>>> On Jan 17, 2010, at 2:39 PM, Thorbjørn Lindeijer
>>> <bjorn at lindeijer.nl>
>>> wrote:
>>>
>>>
>>>
>>>> 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.
>>>>
>>>> Regards,
>>>> Bjørn
>>>> _______________________________________________
>>>> ENet-discuss mailing list
>>>> ENet-discuss at cubik.org
>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>
>>>>
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>
>>>
>>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100117/7ba3e539/attachment-0001.htm>