[ENet-discuss] A query about channels

Alex Milstead alex.milstead at gatech.edu
Sun Jan 17 12:25:59 PST 2010


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
>    



More information about the ENet-discuss mailing list