[ENet-discuss] Fwd: Re: What about a custom packet pattern?
smartin at freedomfactorystudios.com
Thu Apr 14 04:56:03 PDT 2011
Just to clarify, it's a hardware requirement of the platform I'm
developing for to send physical UDP packets in this form.
e.g. I need to send a physical UDP packet like this:
[ (1 byte)1 ] [ (1 byte) user_id ] [ (80 bytes)voicedata ]
[ (1 byte)10 ] [ (1 byte) user_id, (9 bytes) text_message ] [ (0
El 14/04/2011 13:42, Daniel Aquino escribió:
> Doesn't sound right to me. Your hard coding enet into only having the
> ability to create packets with voice data shoved onto them. That's not
> very flexible.
> You can put any data you want into the packet so nothing stops you from
> making all your packets in the desired format.
> But the whole point of channels is to separate such data and treat them
> Normally for voice packets you would send them on their own channel
> using unreliable + sequenced. This way late packets would be dropped
> which is desired for voice.
> Also Enet is not going to send a physical udp packet until you flush the
> host. So if you were to send a game packet and then send a voice packet
> and call flush they would both end up in the same udp packet on the wire.
> On Thu, Apr 14, 2011 at 6:40 AM, Sergio Martin
> <smartin at freedomfactorystudios.com
> <mailto:smartin at freedomfactorystudios.com>> wrote:
> In order to meet our client custom network requirement, I need to
> send each UDP packet data as following:
> [ size_of_game_data ] [ game_data ] [ voice_data ]
> How difficult would be to modify ENet behaviour to meet that pattern?
> I'm not sure how to deal with ENet's packet fragmentation.
> I'm thinking of adding to ENetPacket struct two new variables:
> enet_uint8 * voiceData; /**< allocated voice data for
> packet */
> size_t voiceDataLength; /**< length of voice data */
> Change: enet_packet_create (const void * data, size_t dataLength,
> enet_uint32 flags)
> To this: enet_packet_create(const void * data, size_t dataLength,
> const void * voiceData, size_t voiceDataLength, enet_uint32 flags)
> And then modify the rest of ENet to support it.
> Is this the correct approach?
> Best Regards,
> Sergio Martin.
> ENet-discuss mailing list
> ENet-discuss at cubik.org <mailto:ENet-discuss at cubik.org>
More information about the ENet-discuss