Rerror raising and handling

[Dieter Van Eessen]

Hello,

Thank you for the replies to my previous question.

- I've got another question regarding the Rerror message: when a transaction on a connection was replied with an Rerror, what must happen with the connection? Close by server (after sending Rerror)/ close by client (after receiving Rerror) or can you just keep on using the connection?

- If a client can send multiple Tmessages on a connection without waiting for the response, what if the message size is smaller or larger than the actual message. (wrongly calculated or a badly transferred). It's makes sense the server should respond with an Rerror, but I don't really get how to determine such an error was made. Only in case message size is larger and no more bytes are available on the stream, the socket will tell you. But what in other scenarios?

kind regards,

Dieter Van Eessen

[L29Ah]

On Tue, May 11, 2021 at 01:15:13PM -0700, Dieter Van Eessen wrote:
> Thank you for the replies to my previous question.
> - I've got another question regarding the Rerror message: when a
> transaction on a connection was replied with an Rerror, what must happen
> with the connection? Close by server (after sending Rerror)/ close by
> client (after receiving Rerror) or can you just keep on using the
> connection?

You can.

> - If a client can send multiple Tmessages on a connection without waiting
> for the response, what if the message size is smaller or larger than the
> actual message. (wrongly calculated or a badly transferred). It's makes
> sense the server should respond with an Rerror, but I don't really get how
> to determine such an error was made. Only in case message size is larger
> and no more bytes are available on the stream, the socket will tell you.

It won't. TCP isn't message-oriented and doesn't impose any timeouts by itself.
Generally your peer will wait forever for the remaining part of your message.

--
() ascii ribbon campaign - against html mail
/\ http://arc.pasp.de/ - against proprietary attachments

[Charles Forsyth]

> - I've got another question regarding the Rerror message: when a
> transaction on a connection was replied with an Rerror, what must happen
> with the connection? Close by server (after sending Rerror)/ close by
> client (after receiving Rerror) or can you just keep on using the
> connection?

T requests have tags and R replies have matching tags. That Rerror will have the tag of the original request.

An Rerror response will satisfy the T request with the same tag, just as the specific reply woud (eg, Read for Tread).

The error is for that tagged request, not for the connection, so you not only can but should continue to use the connection.

the size field for a message determines its size. if the content then is wrong for that size, the side that sent it is in error.

In Plan 9, that's detected by convM2S.

that's at a different level than Rerror: messaging on the connection is fundamentally wrong. since messages have a size field,

assuming that's not the thing that's wrong, the receiver can resync easily enough, but it's essentially an internal (programming) error,

if it's not a network fault, and one might as well shut the connection down. In fact, Plan 9's own devmnt attempts to blunder on, but it's fairly arbitrary

who gets the Emountrpc error in the end, because the connection is multiplexed.

--

---
You received this message because you are subscribed to the Google Groups "9p-hackers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 9p-hackers+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/9p-hackers/20210511203116.xhzpadvspvdbm74o%40l29ah-x201.l29ah-x201.

[Dieter Van Eessen]

thank you both for your answer