quicer messages

[klacke]

I'd like to have a discussion on a couple of the various quicer messages a caller receives. I've been doing a bit of quicer programming the last couple of weeks and I'm wondering why a user would ever be interested in the
peer_send_shutdown and the send_shutdown_complete messages. Especially a caller that calls close_stream() is highly uninterested in these messages. If we want to mimic other close() functions, it should be less complex() on behalf of the user/caller. This exposes protocol details, it's like getting a FIN_sent erlang message when executing gen_tcp:close().
Opinions please?

Another message that I'm not using, and I'm wondering about the usecase for this message, is the streams_available message, what is the usecase.

[qzhuyan]

peer_send_shutdown means the peer has finished the transmission of the request data gracefully but it may still receive for the response (not necessarily).

It tells:

1. It is a half shutdown. It close the send part but recv is still open.
2. the stream is shutdown by peer explicitly not due to lower level connection issue or application error (abortive shutdown (peer_send_aborted) for comparison)
3. For streaming mode, the streaming is over and all data are transmitted. Receiving side could start releasing the resource gracefully.
4. For req/resp mode, the whole request data is sent complete, and receiver could start to handle the request without buffering for waiting for more messages due to the application layer message boundaries.
5. There will not be cancelling of the request/data.
   On the opposite, shutdown stream abortively could mean the request is cancelled.

I think QUIC protocol is more transparent to the application so either endpoint of a stream could fine control the behavior of shutdown the stream of its direction and peer side of the stream could react differently.

for peer_send_shutdown it is just another direction that the stream we closed sending locally has been acked by remote. We could assume the server is handling our request with graceful flag set. Or without graceful flag our request is aborted by peer either due to a crash at peer side or request data is malformed and the application could react quickly without even wait for receiving error response on application level.

streams_available reports the flow control on number of allowed streams at peer side and this could be updated in real time. For example server could allow more incoming streams if the client pass the validation but at the beginning of the connection server only allows fewer stream.

I understand not all the events from QUIC stack are interested to application (such like streams_available for single stream application ) so we will have a event mask to control which event should be reported to the owner.