[ENet-discuss] ENetPacket to std::string

Nuno Silva little.coding.fox at gmail.com
Mon Mar 28 09:15:20 PDT 2011


Well, chat messages still need some binary data, otherwise you have no idea
who is sending messages to whom or you will only be able to support a
"general chat" protocol. So at the very least you'd need a few bytes to
define the channel that's being updated (e.g., General and "Team" like
Valve's Source Engine games and mods).

After that you can just copy the bytes after that bit of binary data,
something like, knowing your first x bytes are binary, instead of using
std::string my_string ((char*)packet->data, packet->dataLength);,
use std::string my_string (((char*)packet->data) + x, packet->dataLength -
x);

On Mon, Mar 28, 2011 at 4:59 PM, ingmar wirths <ingmania at googlemail.com>wrote:

> Thanks for your answers.
> I thought there was an easier solution and i was just doing something
> stupid.
>
> Nuno: Of course, i do not embed my game data into strings. I was just using
> this for chat messages. My idea was to send chat messages on a dedicated
> channel reliably, and pass them around in my application as strings.
>
> Maybe this approach isn't that sound? How have you guys implemented
> chatting?
>
> Cheers,
> ingmar
>
> 2011/3/28 Nuno Silva <little.coding.fox at gmail.com>:
> > Just as a follow up to my previous post, you should never use text-based
> > packets, especially on UDP, unless you're going for a HTTP-esque protocol
> > where everything is pretty much text. The reason for this is that you can
> > always encode pretty much anything into binary, which becomes much
> smaller
> > than anything text.
> >
> > As an example, let's say you want to tell a game server that the player
> with
> > ID 123 is going to teleport to gate 567. Originally, as text, it could go
> > like "Teleport Player:123 Gate:567". In binary, it could fit into about
> 12
> > bytes or less, vs the text version that takes 27 bytes.
> >
> > The reason UDP should always use binary packets is mainly what i just
> said
> > but also because UDP as a protocol is unreliable, even if Enet has
> reliable
> > packets. That means that if you send huge packets (like 128KB or so),
> it'll
> > almost never reach its destination unless it is really close by.
> >
> > On Mon, Mar 28, 2011 at 4:33 PM, Daniel Aquino <
> mr.danielaquino at gmail.com>
> > wrote:
> >>
> >> A quick google search gave this link where the last post sounds like it
> >> might be your answer:
> >>
> >> http://www.codeguru.com/forum/showthread.php?t=231155
> >>
> >> But that's really a c++ question not ENet.
> >>
> >>
> >>
> >> On Mon, Mar 28, 2011 at 11:26 AM, ingmar wirths <
> ingmania at googlemail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> i'm getting a little frustrated trying to put the content of a packet
> >>> into a string.
> >>> What i simply want to do is something like:
> >>>
> >>> std::string my_string (packet->data, packet->dataLength);
> >>>
> >>> This doesn't compile however. I kind of get the idea why not, fiddled
> >>> around a little,
> >>> but could'nt get it working.
> >>>
> >>> I guess someone did this before, any ideas?
> >>>
> >>> Thanks,
> >>> ingmar
> >>> _______________________________________________
> >>> 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/20110328/89deb320/attachment.html>


More information about the ENet-discuss mailing list