A protocol library sends complete messages (partial messages are not directly supported as part of the spec). In order to send large data through the protocol, another spec introduces the concept of segmenting the message body into blocks. The requester sends those blocks where the final block is flagged as the last block, then reads a response block-wise message from the responder until the last block is read (again flagged as last block).
The sending and receiving operations are exclusive that may not be interleaved.
For anyone interested, I'm implementing RFC 7959 - Block-Wise Transfers in the Constrained Application Protocol (CoAP)
In order to accomplish this in .Net a BlockStreamWriter is implemented that will create a new message with each block of data written and send it. When the stream's Dispose() method is called, the final block is sent with a flag signaling the end. There is a complimentary BlockStreamReader that reads incoming blocks until the last block signal is received.
Is this the correct way to utilize .Net's Stream for writing data?
If I wanted to create a single stream implementation that could write and then read, what would be the correct way to signal no more to write?
My concern comes from the nature of the protocol, where the last message received from acknowledging the last block received may have a message ID and information regarding the response of a block-wise message that I need to pass onto the reader stream. which is difficult when the writer is disposed
