Home/ Questions/Q 7695645
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T21:35:27+00:00

I am using $SUB for the first time and have come across this problem.

  • 0

I am using $SUB for the first time and have come across this problem. Both, client and server use overlapped operations and here is the specific situation I have a problem with.

Client

C1. Connects to the server.
C2. Sends the message bigger than a pipe buffer and buffer passed to overlapped read operation in the server.
C3. Successfully cancels the send operation.

Server

S1. Creates and waits for the client.
S2. When the client is connected, it reads the message.
S21. Because message doesn’t fit into the buffer(ERROR_MORE_DATA), it is read part by part.

It seems to me that there is no way to tell when is the whole message, as an isolated unit, canceled. In particular, if client cancels the send operation, server does not receive the whole message, just a part of it, and consequent read operation returns with ERROR_IO_PENDING (in my case), which means there is no data to be read and read operation has been queued. I would expect to have some kind of means telling the reader that the message has been canceled, so that reader can act upon it.

However, relevant documentation is scatter over MSDN, so I may as well be missing something. I would really appreciate if anyone can shed some light on it. Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are correct, there is no way to tell.

    If you cancel the Writefile partway through, only part of the message will be written, so only that part will be read by the server. There is no “bookkeeping” information sent about how large the message was going to be before you cancelled it – what is sent is just the raw data.

    So the answer is: Don’t cancel the IO, just wait for it to succeed.

    If you do need to cancel IO partway through, you should probably cut the connection and start again from the beginning, just as you would for a network outage.

    (You could check your OVERLAPPED structure to find out how much was actually written, and carry on from there, but if you wanted to do that you would probably just not cancel the IO in the first place.)

    Why did you want to cancel the IO anyway? What set of circumstances triggers this requirement?

    • 0