2

In my single-threaded app I use 

SDLNet_CheckSockets -> SDLNet_SocketReady -> SDLNet_TCP_Recv

chain in order to receive packets without blocking. I use 512 as the buffer size when calling SDLNet_TCP_Recv. And most of the time packets fit well into that. But what if I receive several packets at once? Or large packets?

  1. I can't blindly call SDLNet_TCP_Recv multiple times because I don't know if it will block or not. If there isn't any more data it blocks. If I receive one packet which is exactly the size of my buffer then I will have no idea if there are more of them waiting or not.
  2. Calling SDLNet_SocketReady after each SDLNet_TCP_Recv call doesn't work. It only returns true the first time. Then it returns false even when there is actually more data to read (tested it by blindly calling SDLNet_TCP_Recv when SDLNet_SocketReady returned false).
  3. Calling SDLNet_CheckSockets after every SDLNet_TCP_Recv call looks to me as a very bizarre option. Surely this is not the way? Why do I have to consider ALL sockets each time I read a few more bytes from one socket? That ruins class structure of my program and requires dirty hacks to work.

All tutorials and examples that I see don't concern themselves with the possibility that a socket can receive more data than its buffer size (which is typically small). As if it doesn't happen. But surely it does happen, websockets can express their size with a 64-bit integer. I don't want to allocate that much unless I know I have to. And, again, several small packets can simply stack up.

How should I approach this?

Using UDP is not an option since I deal with websockets.

aesca
  • 19
  • 4
  • You seem to be a bit confused about the nature of TCP. It's an octet, (byte), streaming service. If you want to transfer 'packets' or 'messages' longer than one byte, you need a protocol on top that defines how to send your application protocol units at the sender how to parse the required APU out at the receiver. Buffer size is therefore just an optimization exercise and, indeed, a socket cannot receive more data than its buffer size. – Martin James Apr 02 '18 at 05:26
  • Also, reading again, 'single-threaded' and ' do I have to consider ALL sockets' well, if you are handling multiple TCP socket streams with a message-protocol on top, (eg. HTTP), then I'm afraid that you are going to need explicit, user-code-managed, state-machines. – Martin James Apr 02 '18 at 05:31
  • @MartinJames When I say "packets" I mean chunks of data that have arrived since the last time I checked. I assume SDLNet has some sort of internal buffer because it can have data just "sitting" there, waiting for me to read it into my buffer. The problem with multiple sockets is that the only way to check if there is more data available already in one of my sockets - is to check ALL my sockets first. The socket could have received 1kb of data already but if my buffer size is 128b I will have to check ALL sockets 8 times to read that filthy 1Kb from it. – aesca Apr 03 '18 at 11:47

0 Answers0