[ENet-discuss] I am puzzled with the flow of send buffer

[JiangHao]

thanks for your reply .
   my point is the same bufffers is send to the different address of the
peers.because the function 'enet_socket_send' is called in a loop of the
host's peers and the buffer argument of the function is allways
'host->buffers',
   why the content  is send to all other peer  which is only send to peer A


2012/7/30 Lee Salzman <lsalzman at gmail.com>

> The packet gets sent to the address of the peer, so it is thus received by
> the remote host. The packet is tagged with the id of the destination peer,
> so the remote host only has to index into its array of peers with that id.
> After, it compares the address in the peer with the address of the packet's
> sender to verify the packet came from the right source. There's no real
> performance penalty for this.
>
> On Mon, Jul 30, 2012 at 8:35 AM, JiangHao <jaxecn at gmail.com> wrote:
>
>> hello ,
>>      I'm leaning the enet libaray,and i am puzzled with the flow of send
>> buffer when i reading
>> the implementation of enet_protocol_send_outgoing_commands,
>>
>>      here is: sentLength = enet_socket_send (host -> socket, &
>> currentPeer -> address, host -> buffers, host -> bufferCount);
>>       Is I made a mistake or you have it in the design?  will it send the
>> same buffers to all  the peers of one host  and filtered by
>> remote host when it has receved these buffers.?
>>       the performance is not affected if  it is  send to all peers.is it?
>>
>>
>>       forgive my poor english .and thanks for answer.
>>
>>
>>
>> _______________________________________________
>> 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/20120730/10c4ee5d/attachment.html>