Relay enters irresponsive state after SOCKS server restarts (plus several other issues)

[Alejandro Cuevas]

Description: If the public SOCKS server (relay -> SOCKS) is shut down, the relay enters an irresponsive state. That is, the relay stops running rounds despite clients and trustees being available (see Figure 1). Also, if the trustee fails during this period of time as reported in #203, then this emits a SHUTDOWN message which causes the iOS client to disconnect and also enter a buggy state (see Figure 2; this is a separate issue, however). This state persists even if the SOCKS server is started again.

Lastly, upon restarting the relay we can observe a lot of SOCKS errors similar to those described in #204, see Figure 3.

Steps to Reproduce:

1. Set up the protocol (I tested with 1 trustee and the iOS client 1.9.1)
2. I initiated several connections on the client
3. I terminated the SOCKS server
4. At this point, the relay successfully prints the following message and continues to carry out its rounds:

E : ( stream-multiplexer.StartEgressHandler: 76) - Egress server: Could not connect to server, discarding data. Do you have a SOCKS server running on 127.0.0.1:8090 ? You need one! dial tcp 127.0.0.1:8090: connect: connection refused

5. However, after a little while (600-1k rounds) it seems like the relay attempts again to send data to the egress server and at this point it becomes irresponsive (stopping its rounds).
6. Sometimes, it seems like the relay attempts to restart the protocol but it's unable to follow through since it simply stays frozen in the preamble (as seen in Figure 1).
7. Additionally, during this irresponsive state, #203 also occurs and causes the behavior described above (i.e. causing the iOS app to enter a buggy state)
8. Upon restarting the relay, the SOCKS server sees all sorts of errors similar to those described in #204 (EOF and Bad Version), see Figure 3.
9. Finally, I had www.google.com open as one of the connections in step 2). I can confirm that after step 8) I was unable to load www.google.com but could surf other websites (which were not open in step 2) normally. This behavior is described in #207.

Figure 1

Figure 2

Figure 3