patterncsharpMinor
Websockets client code and making it production-ready
Viewed 0 times
productionandwebsocketsclientreadycodemaking
Problem
The following code is helpful to anyone who uses websockets in general... and is probably good template for anyone getting started in this area. I'd like to flesh this out into something that is more general purpose, and reusable, since the assumptions and questions I have will apply to many different situations.
Assumptions:
-
The Timespan "Delay" is used to tell the server my client is OK and refreshes the subscription. Issuing this to the server too often is a waste of resources, and issuing it too late may cause a server-defined timeout.
-
The receive chunksize is only how my client is talking to a network buffer. Delays in this do not affect the server. (unsure of this)
-
The
Questions
-
What must be done to make this code production ready?
-
How do I determine the optimal chunk size for send and receive?
-
How should I recover from an error in the code, the network, or a server error?
-
How do I ensure that the data I'm getting is complete, and not just a fragment of data, cut off in mid-transition simply because the rest of the data is stuck in the buffer?
Code
```
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.WebSockets;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace BlockchainInfoWebSockets
{
class Client
{
private static object consoleLock = new object();
private const int sendChunkSize = 256;
private const int receiveChunkSize = 256;
private const bool verbose = true;
private static readonly TimeSpan delay = TimeSpan.FromMilliseconds(30000);
static void Main(string[] args)
{
Thread.Sleep(1000);
Connect("ws://ws.blockchain.info:8335/inv").Wait();
Console.WriteLine("Press any key to exit...");
Assumptions:
-
The Timespan "Delay" is used to tell the server my client is OK and refreshes the subscription. Issuing this to the server too often is a waste of resources, and issuing it too late may cause a server-defined timeout.
-
The receive chunksize is only how my client is talking to a network buffer. Delays in this do not affect the server. (unsure of this)
-
The
WebSocketStatus can be other values, such as closed, opening, etc., and this code isn't production ready since I don't handle those events.Questions
-
What must be done to make this code production ready?
-
How do I determine the optimal chunk size for send and receive?
-
How should I recover from an error in the code, the network, or a server error?
-
How do I ensure that the data I'm getting is complete, and not just a fragment of data, cut off in mid-transition simply because the rest of the data is stuck in the buffer?
Code
```
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.WebSockets;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace BlockchainInfoWebSockets
{
class Client
{
private static object consoleLock = new object();
private const int sendChunkSize = 256;
private const int receiveChunkSize = 256;
private const bool verbose = true;
private static readonly TimeSpan delay = TimeSpan.FromMilliseconds(30000);
static void Main(string[] args)
{
Thread.Sleep(1000);
Connect("ws://ws.blockchain.info:8335/inv").Wait();
Console.WriteLine("Press any key to exit...");
Solution
- You may want to be using
CancellationTokens via the overload for the async methods of theClientWebSocketclass to properly cleanup tasks on exit.
- 1024 is usually the value I like to use for web connectivity, the MTU (Maximum Transmission Unit)1 for Ethernet is 1500 bytes, and I like to round that down to a near exponent of 2, in this case 2^10.
- I'm not all sure about the
ClientWebSocketclass, but you will either get aWebExceptione.g. 404, I think in the StatusCode, or else it may be thatWebSocketStatusyou were talking about. Logging these exceptions may be the only thing you can do.
- Unless you have access to the source code of the server on the otherside and are able to make changes to it, unless the server implements some way to tell how much data it is sending, there's no way to be sure. An example would be the first 4 bytes of the transmission is the length of the data.
Context
StackExchange Code Review Q#41591, answer score: 5
Revisions (0)
No revisions yet.