StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I have a <a href="http://blog.stephencleary.com/2009/04/tcpip-net-sockets-faq.html" rel="nofollow">.NET TCP/IP FAQ</a> that I recommend to get some of the basics down.</p> <p>After just a brief look at your code, these points stood out to me:</p> <ol> <li>Both your client and server have times when they're only reading (not writing). This means you're subject to the <a href="http://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html" rel="nofollow">half-open scenario</a> (as I describe in my FAQ). A robust server should be writing periodically even if it has nothing to say.</li> <li>Both your client and server have times when they're only writing (not reading). This means that you're <a href="http://blog.stephencleary.com/2009/06/using-socket-as-connected-socket.html" rel="nofollow">subject to a deadlock</a> (as I describe in my FAQ) if the other end is not behaving well (e.g., sending lots of data). However, you can't just read indefinitely or you'll open yourself up to a DoS; so you should decide where your limit is and establish read buffer sizes (and write timeouts) that make sense for your application.</li> <li>Using <code>ReadLineAsync</code> leaves you open to a trivial DoS attack, since you can't specify the maximum allowed size of the line.</li> <li><a href="http://blog.stephencleary.com/2009/05/error-handling.html" rel="nofollow">Your code must be prepared for an exception at any time</a> (as I describe in my FAQ). Obviously, <code>ReadAsync</code> and <code>WriteAsync</code> may throw. What's less obvious is that <em>any</em> socket method may throw, including <code>AcceptTcpClientAsync</code>.</li> <li>Your code uses a mixture of exception handling types. The <code>async Task</code> methods are never awaited, so exceptions there just silently end that method. The <code>StartClient</code> method is more problematic, since it is <code>async void</code>. You'll need to think through your application needs for error detection and retry strategies, and apply proper handling at every level.</li> </ol> <p>In conclusion, I reiterate my comment: I <em>strongly</em> recommend just self-hosting SignalR. Sockets should <em>only</em> be used if you have no choice.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload