🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Ghost Packets
Author
OK, this is a good one. I figured out my last problem by sticking a while loop in my FD_WRITE message handler that kept sending packets until they could be sent no more (read: I get a WSAEWOULDBLOCK error). Now this crops up and while I''m still trying to debug it, lets see what you think.
the problem is that for some reason there are a few empty packets sent. Now my packets are all structures, so in this case the fields are empty (btw, I do a memset on my PACKET instance each time around since I have an imbedded header I only send once and i don''t want it filled with junk after the fact). I know that there are empty packets being sent in two ways -
1) I read 500 bytes of data for each packet. At the end of the program, I display the # of bytes and packets sent. The number of bytes always exceeds the value of 500*#packets sent. This means that more than one packet was sent with the number zero (the index field wasn''t set).
2) My server kills the transmission early. I have a int flag to let the server know when the last packet has been received. That flag is a value of zero. Guess what? When a packet with a 0 .index field is received, it also has a zero file .field, so my server thinks its the end of the file.
If that''s not mysterious enough, the fact that the program displays more bytes sent than should have for the # of packets sent, that means my variable that holds # bytes ent is incrementing each loop while a dummy packet is sent!!! I dunno if any of this makes sense to you in any way since you don''t have the code. I''ll try changing my EOF value to 1 instead of zero an see if that works. It might, but that still doesn''t explain why I''m sending these empty packets. If you want the code to my FD_WRITE message handler, just ask. Thanks.
==============================
"Need more eeenput..."
- #5, "Short Circuit"
==============================
Now first of all, i dunno if i have understood the problem completely but i want to point u to some possible tripwires...
First, it seems to me that u expect that if u send like 500 bytes on the one site, u will always receive 500 bytes for each FD_READ on the other side. This is wrong (sadly, i had to encounter this also the hard way). TCP is a stream protocol, and u never know how the data that u pass to the tcp layer with send() arrives at the other site: it might be one 500 byte packet, it might be that the sendbuffer put 2 sends together and u receive 1000 bytes (so actually u received 2 packets), or u get only part of a packet (e.g. 250 bytes..). So your receive handler must be able to sort this all out, multiple messages arriving in one FD_READ, partial messages arriving, or what ever combination u can think of. What u CAN be sure of course is that the data arrives in the correct order, and that everything WILL be transmitted. But not how much/many of a message arrives on the other side.
Second, i dont know if u have a misunderstanding with the FD_WRITE handling. The point of the FD_WRITE event is that it occurs when ONE send was blocked and the port is free again, this means that in the message handling for the FD_WRITE u just resend the ONE SINGLE send that was blocked before (WSAEWOULDBLOCK). SO generally, in your normal application flow u process everything as normal and issue your sends when needed,
and if a send is blocked (getting wsaewouldblock as rc) u will be notified thru FD_WRITE when the port is able to send data again. The problem is of course that u have to make sure in application flow that if u had ur send blocked, u are not issuing further sends (which will receive WSAEWOULDBLOCK as well) until the FD_WRITE event occured.
Thats it from my point of view, hope i could help u a bit. I cant
help u on the source coz i do my stuff in w32bit assembly. But iam sure most others here can provide this help.
Good luck,
Ice.
First, it seems to me that u expect that if u send like 500 bytes on the one site, u will always receive 500 bytes for each FD_READ on the other side. This is wrong (sadly, i had to encounter this also the hard way). TCP is a stream protocol, and u never know how the data that u pass to the tcp layer with send() arrives at the other site: it might be one 500 byte packet, it might be that the sendbuffer put 2 sends together and u receive 1000 bytes (so actually u received 2 packets), or u get only part of a packet (e.g. 250 bytes..). So your receive handler must be able to sort this all out, multiple messages arriving in one FD_READ, partial messages arriving, or what ever combination u can think of. What u CAN be sure of course is that the data arrives in the correct order, and that everything WILL be transmitted. But not how much/many of a message arrives on the other side.
Second, i dont know if u have a misunderstanding with the FD_WRITE handling. The point of the FD_WRITE event is that it occurs when ONE send was blocked and the port is free again, this means that in the message handling for the FD_WRITE u just resend the ONE SINGLE send that was blocked before (WSAEWOULDBLOCK). SO generally, in your normal application flow u process everything as normal and issue your sends when needed,
and if a send is blocked (getting wsaewouldblock as rc) u will be notified thru FD_WRITE when the port is able to send data again. The problem is of course that u have to make sure in application flow that if u had ur send blocked, u are not issuing further sends (which will receive WSAEWOULDBLOCK as well) until the FD_WRITE event occured.
Thats it from my point of view, hope i could help u a bit. I cant
help u on the source coz i do my stuff in w32bit assembly. But iam sure most others here can provide this help.
Good luck,
Ice.
Author
EOF is my own constant (actually its EOFT end of file transfer)
==============================
"Need more eeenput..."
- #5, "Short Circuit"
==============================
==============================
"Need more eeenput..."
- #5, "Short Circuit"
==============================
Ah I see.
What value does this EOFT have?
There exist a distinct possiblity, in fact probability, that whatever value you chose for an EOFT will appear in the data stream. If you filter the entire data stream looking for this EOFT it will prematurely terminate the transmission. And constantly looking for that EOFT waste cpu time.
Typically, the first thing you send is how much data you are going to send, use 4 bytes ie a DWORD. Often you finish with a Check Sum, CRC, or ECC (which one, if any, is known ahead of time, and the space needed for the check code is included it those first four bytes). The actual file data is between those first 4 & last ~4 bytes (for the CS, CRC, or ECC). Often header data is included (as with HTTP) that not only has the amount of data coming, but the original file date & time as well.
If you''re sending UDP packets, you can ask WSA for the amount of data on receive. If you''re using TCP, you need to send a size with the packets.
What value does this EOFT have?
There exist a distinct possiblity, in fact probability, that whatever value you chose for an EOFT will appear in the data stream. If you filter the entire data stream looking for this EOFT it will prematurely terminate the transmission. And constantly looking for that EOFT waste cpu time.
Typically, the first thing you send is how much data you are going to send, use 4 bytes ie a DWORD. Often you finish with a Check Sum, CRC, or ECC (which one, if any, is known ahead of time, and the space needed for the check code is included it those first four bytes). The actual file data is between those first 4 & last ~4 bytes (for the CS, CRC, or ECC). Often header data is included (as with HTTP) that not only has the amount of data coming, but the original file date & time as well.
If you''re sending UDP packets, you can ask WSA for the amount of data on receive. If you''re using TCP, you need to send a size with the packets.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement