Hi folks, I'm looking for what kinds of errors and how should the client be able to recover from them when it comes to using the nconnect feature. My first question: what kind of failures seem reasonable? Say the client has 3 connections to the server (nconnect=3). Is it possible that one of those functions breaks? For instance, I simulate this with blocking any requests on that connection and sending an RST back to the client. Besides an RST, are there any other interesting errors that should be considered (ICMP port unreachable perhaps. In this case the client keeps trying to send the same packet it sent before. In RST, client tries to send a SYN)? If the client had sent a request on that particular connection but didn't get a response and now the connection is being RSTed. Should the client 'give up' and send the same request on a different connection? For v3,v4 I can see that it's a problematic idea because the reply cache is based on the port. Current client behaviour is that: client does not retry. Am I correct in assuming that it shouldn't be changed? I'm assuming that an application that issued that operation will hang (as in a single TCP connection case). Once that transport is occupied, the other transports are still available to send requests over to the server un-obstructed. My next question: should there be any connection badness detection? As this transport is not marked in anyway and can be selected by another RPC (if the previous request was ctrl-C-ed, releasing the transport into the transport pool). Thank you.
