0

I'm currently implementing IOCP server for a game and I'm trying zero bytes recv technic.

I have 3 questions.

  1. If you know disconnection from the client by checking if bytestransferred is 0, then how do you distinguish between receive completion and disconnection?

  2. I'm not performing non-block mode recv() when I process actual receive process because clients send the bytes of actual data first, so I know how many bytes I'm receiving. Do I need to use non-block mode recv() still?

I'm doing it like so.

InputMemoryBitStream incomming;
std::string data;
uint32_t strLen = 0;

recv(socket, reinterpret_cast<char*>(&strLen), sizeof(uint32_t), 0);
incomming.resize(strLen);
recv(socket, reinterpret_cast<char*>(incomming.getBufferPtr()), strLen, 0);
incomming.read(data, strLen);

(InputMemoryBitStream is for reading compressed data.)

  1. I'm dynamically allocating per io data every time I do WSARecv() and WSASend() and I free them as soon as I finish processing completed I/Os. Is it inefficient to do that? or is it acceptable? Should I reuse per io data maybe?

Thank you in advance.

bugfreerammohan
  • 1,471
  • 1
  • 7
  • 22
Jeongmin Heo
  • 61
  • 1
  • 7
  • When performing an IOCP request, you can pass context information inside your `OVERLAPPED` struct. You can use that to flag your requests. When receiving completion notifications, you will know which type of request is notifying you and can act accordingly (ie, ignore `BytesTransferred` for zero-byte recvs) – Remy Lebeau Jan 11 '19 at 14:03
  • exist sense everywhere use asynchronous I/O. so never use blocking calls like `recv`. and for what you use zero bytes recv - i think bettwer always pass not empty buffer for recv. and when you receive 0 bytes - you know that disconnect happens – RbMm Jan 12 '19 at 13:21

0 Answers0