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

[Chris Jurney]

It can also be a false positive if your packet looks kinda sorta like some
other protocol.

On Sun, Jan 17, 2010 at 7:19 AM, Jay Sprenkle <jsprenkle at gmail.com> wrote:

> From my reading malformed packets are usually caused by flaws in hardware.
> There are reports of poor network cables, cards, device drivers, and tcp
> stacks on various machines. I'd try sending from a different machine and see
> if the problem is resolved.
>
>
> On Sun, Jan 17, 2010 at 3:55 AM, Alex Milstead <alex.milstead at gatech.edu>wrote:
>
>> Thanks a bunch, Lee! That did it. Still doesn't quite explain the
>> "malformed packet" information I was receiving from wireshark, although
>> since I'm actually getting the packets this time, I suppose that doesn't
>> really matter much.
>>
>> Cheers,
>> Alex
>>
>>
>> On 1/15/2010 12:25 PM, Lee Salzman wrote:
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Cause united breaks guitars
> http://www.youtube.com/watch?v=5YGc4zOqozo
>
>
> _______________________________________________
> 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/20100117/43eae0ff/attachment-0001.htm>