Interesting packet loss situation
If you're using TCP, then you may very well receive more than one packet in the same receive call. In fact, you could be receiving half a packet in one call, and one and a half in another. This is further explained in the Forum FAQ. However, from the other descriptions of your system it sounds like you're using UDP, in which case you get a whole, single packet or nothing at all in each receive call.
Author
It is true, yes, that I am using TCP. However, I have indeed written an original packet system, that in fact could definitely be "better," (I don't compress or 'que' the packets, for example) but I'm quite proud of it in fact otherwise. Packet sizes and types are passed as the packet header, and enumerators and reflections are used to lookup and invoke said packet. The entire packet system is compile into a .dll in fact. It also delineates these packets, so generally it actually runs very well. (The delineations fixed the original double-packet issue)
As it stands now, the buffer sizes have corrected the problem. I can send multiple packets at any time during any given thread, and the clients handle them fully. :) Apparently I had underestimated my buffer usage when I had them set at 64k. Of course, I say that now... who knows after a few hundred more lines of code? You know how that goes!
As it stands now, the buffer sizes have corrected the problem. I can send multiple packets at any time during any given thread, and the clients handle them fully. :) Apparently I had underestimated my buffer usage when I had them set at 64k. Of course, I say that now... who knows after a few hundred more lines of code? You know how that goes!
Quote:Original post by KODOnline
It is true, yes, that I am using TCP. However, I have indeed written an original packet system, that in fact could definitely be "better," (I don't compress or 'que' the packets, for example) but I'm quite proud of it in fact otherwise. Packet sizes and types are passed as the packet header, and enumerators and reflections are used to lookup and invoke said packet. The entire packet system is compile into a .dll in fact. It also delineates these packets, so generally it actually runs very well. (The delineations fixed the original double-packet issue)
Be careful when building reflective objects from the network stream. Ask yourself what your system will do if I find the 'size' value in the packet and set it to 4 billion.
Ask yourself what would happen if someone sent a serialized HardDiskFormatterObject (or something similar) instead. If you're using plain serialization from a system library, you don't have as much control over what gets created as you'd have with a custom system.
I am currently working on a multiplayer card game using the c# socket implementation. And, like you I have had very weird packet losses between the server (multi-threaded) and client. The same as you when you send packets very quickly after another.
The way my system was setup, I used TcpClient to connect to the server, then got a NetworkStream from the TcpClient and then in turn created StreamReader and StreamWriter to interface with the network stream. I don't know if it was my wrong implementation of using the streams, or the streams themselves but I had the same problem. I just recently fixed this by using straight sockets to send and recive data with byte arrays. For instance, i just to socket.receive(byteArray, size, options) and I now works correctly.
I can't really help with the problem, but if your using streams to read and write I would suggest to change to socket.receive and socket.send and see if it works then.
The way my system was setup, I used TcpClient to connect to the server, then got a NetworkStream from the TcpClient and then in turn created StreamReader and StreamWriter to interface with the network stream. I don't know if it was my wrong implementation of using the streams, or the streams themselves but I had the same problem. I just recently fixed this by using straight sockets to send and recive data with byte arrays. For instance, i just to socket.receive(byteArray, size, options) and I now works correctly.
I can't really help with the problem, but if your using streams to read and write I would suggest to change to socket.receive and socket.send and see if it works then.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
