[ENet-discuss] Long Distance Packet Loss (maybe)?

Lee Salzman lsalzman1 at cox.net
Fri Jan 15 09:25:14 PST 2010


enet_host_flush just sends the packet only once. If the packet gets 
lost, enet_host_service ensures it gets resent until it is delivered.

Lee

Alex Milstead wrote:
> On 1/15/2010 11:28 AM, Lee Salzman wrote:
>> Are you regularly calling enet_host_service on the client?
>>
>> Lee
>>
>> Alex Milstead wrote:
>>> Hey all,
>>>
>>> Just a heads up, (I don't know how reliable this is, exactly, but) 
>>> I've been using a network packet monitoring tool call "wireshark" to 
>>> monitor packets coming back and forth between client and server apps 
>>> using an ENet wrapper I wrote.
>>>
>>> I'm using ENet to send a struct back and forth between machines. The 
>>> struct itself isn't very big (only about 10 fields inside), and for 
>>> the longest time sending it to and fro was no big problem. Recently, 
>>> though, I've been testing out the server piece of the app(s) I'm 
>>> writing, and according to wireshark, I'm receiving "Malformed 
>>> Packets". I see this happening pretty frequently between machines 
>>> when the client and server are in the same general (geographical) 
>>> locale, however I've got a team member that is testing the client 
>>> from Oregon (I'm in Georgia), and some seriously screwed up is 
>>> happening. Every time he sends data, wireshark picks up that a 
>>> packet is coming in, but ENet -never- hits the 
>>> "ENET_EVENT_TYPE_RECEIVE" event on the server host that is servicing 
>>> the connection.
>>>
>>> The basic break down of the apps ENet protocols are as follows (sans 
>>> the client connecting to the server for the first time):
>>>
>>> Client code:
>>> ...
>>>
>>> SendData(void *data)
>>> {
>>>    if (connected) // flag set to true when enet_host_connect and 
>>> subsequent (enet_host_service && event.type == 
>>> ENET_EVENT_TYPE_CONNECT) events are true
>>>       ENetPacket *packet = enet_packet_create(struct_ref, 
>>> sizeof(structReferenced), ENET_PACKET_FLAG_RELIABLE);
>>>       enet_peer_send(server, channel, packet);
>>>       enet_host_flush(connection);
>>> }
>>> ...
>>>
>>> Server Code:
>>> ...
>>> while (enet_host_service(connection, &event, connection_lifetime) >= 
>>> 0 && !quit) {
>>>        switch (event.type) {
>>>            case ENET_EVENT_TYPE_CONNECT:
>>>                cout << "A new client connected!";
>>>
>>>                break;
>>>            case ENET_EVENT_TYPE_RECEIVE:
>>>                ProcessPacket(event);
>>>                break;
>>>       }
>>> }
>>> ...
>>>
>>> The problem appears to be when packets are sent from the client 
>>> machine in Oregon. Like I mentioned, wireshark is telling me that 
>>> the packet actually made it, but the ENET_EVENT_TYPE_RECEIVE -never- 
>>> occurs. Again, I'm not sure how reliable "wireshark" is, but it's 
>>> telling me that the UDP packet being sent is "malformed". This 
>>> doesn't seem to happen when I'm sending from a client machine that 
>>> is geographically closer to the server (e.g. in my home, but sending 
>>> requests to the frontal IP instead of a local IP), although 
>>> wireshark still seems to report that the datagram sent from the 
>>> closer machine is also sometimes "malformed".
>>>
>>>
>>> Any ideas on what's happening/going wrong?
>>>
>>> Thanks for any help in advance.
>>>
>>> Cheers,
>>> Alex
>>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
> Yes. The method which calls "SendData", immediately calls 
> enet_host_service afterward to listen for response packets from the 
> server.
>
> Should I be using "enet_host_service(conn, &event, lifetime) && 
> event.type == ENET_EVENT_TYPE_CONNECT" before sending a packet? I 
> thought the purpose of enet_flush_host was to send off packets without 
> having to service the host.
> _______________________________________________
> 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