It can also be a false positive if your packet looks kinda sorta like some other protocol.<br><br><div class="gmail_quote">On Sun, Jan 17, 2010 at 7:19 AM, Jay Sprenkle <span dir="ltr"><<a href="mailto:jsprenkle@gmail.com">jsprenkle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Sun, Jan 17, 2010 at 3:55 AM, Alex Milstead <span dir="ltr"><<a href="mailto:alex.milstead@gatech.edu" target="_blank">alex.milstead@gatech.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
Cheers,<br><font color="#888888">
Alex</font><div><br>
<br>
On 1/15/2010 12:25 PM, Lee Salzman wrote:<br>
</div><div><div></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
Lee<br>
<br>
Alex Milstead wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 1/15/2010 11:28 AM, Lee Salzman wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Are you regularly calling enet_host_service on the client?<br>
<br>
Lee<br>
<br>
Alex Milstead wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey all,<br>
<br>
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.<br>
<br>
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.<br>
<br>
The basic break down of the apps ENet protocols are as follows (sans the client connecting to the server for the first time):<br>
<br>
Client code:<br>
...<br>
<br>
SendData(void *data)<br>
{<br>
if (connected) // flag set to true when enet_host_connect and subsequent (enet_host_service && event.type == ENET_EVENT_TYPE_CONNECT) events are true<br>
ENetPacket *packet = enet_packet_create(struct_ref, sizeof(structReferenced), ENET_PACKET_FLAG_RELIABLE);<br>
enet_peer_send(server, channel, packet);<br>
enet_host_flush(connection);<br>
}<br>
...<br>
<br>
Server Code:<br>
...<br>
while (enet_host_service(connection, &event, connection_lifetime) >= 0 && !quit) {<br>
switch (event.type) {<br>
case ENET_EVENT_TYPE_CONNECT:<br>
cout << "A new client connected!";<br>
<br>
break;<br>
case ENET_EVENT_TYPE_RECEIVE:<br>
ProcessPacket(event);<br>
break;<br>
}<br>
}<br>
...<br>
<br>
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".<br>
<br>
<br>
Any ideas on what's happening/going wrong?<br>
<br>
Thanks for any help in advance.<br>
<br>
Cheers,<br>
Alex<br>
<br>
</blockquote>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</blockquote>
Yes. The method which calls "SendData", immediately calls enet_host_service afterward to listen for response packets from the server.<br>
<br>
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.<br>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</blockquote>
<br>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br><div><div></div><div class="h5">Cause united breaks guitars<br><a href="http://www.youtube.com/watch?v=5YGc4zOqozo" target="_blank">http://www.youtube.com/watch?v=5YGc4zOqozo</a><br>
<br>
</div></div><br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br>