Trade/Quote Subscription broken

Error:

OnError event => Exception: System.InvalidOperationException: Websocket closed with error: MessageTooBig.
at Alpaca.Markets.WebSocketsTransport.startReceiving(WebSocket socket)
9
OnError event => Exception: Alpaca.Markets.RestClientErrorException: invalid syntax

Code:

 foreach(var kvp in SYMBOL_MAP)
 {
                                               
 var trade_subscription = streamingClient.GetTradeSubscription(kvp.Key.symbolCode);
                                        
 trade_subscription.Received += (trade) => {
   System.Console.WriteLine("TRADE: {0} {1}", trade.Symbol, trade.Price);
   };

 var quote_subscription = streamingClient.GetQuoteSubscription(kvp.Key.symbolCode);
                                        
 quote_subscription.Received +=(quote) =>
  {
     System.Console.WriteLine("QUOTE: {0} {1}/{2}", quote.Symbol, quote.BidPrice, quote.AskPrice);
                                    
   };
         streamingClient.SubscribeAsync(trade_subscription);
         streamingClient.SubscribeAsync(quote_subscription);
                                      
   }

also, for some symbols when requesting data. this pops up:

OnError event => Exception: Alpaca.Markets.RestClientErrorException: invalid syntax

@oleg.rakhmatulin any ideas?

The first error (message too big) is new but I have some ideas why it can happen. I’ll open the new GitHub issue about it. For the second one - try the latest stable SDK version and ALWAYS wait for the async method results using the await keyword. Code without await can work 99% of the time but sometimes the behavior of the underlying web socket is unpredictable.

await the GetTradeSubscription/GetQuoteSubscription? I’m a little confused, they don’t appear to be async methods.

No, I mean this lines:

await streamingClient.SubscribeAsync(trade_subscription);
await streamingClient.SubscribeAsync(quote_subscription);

or event better (if you use Extensions package and appropriate namespace):

await streamingClient.SubscribeAsync(trade_subscription, quote_subscription);

@oleg.rakhmatulin I tried both ways (without extensions and with).

I do get data but eventually, this will happen:

Information: 0 : Unable to write data to the transport connection: Connection reset by peer.
Information: 0 : Unable to write data to the transport connection: Broken pipe.
SocketClosed event => Socket closed.

I would like to add that this error message is appearing before the fulllist of symbols is subscribed to. Please let me know as this issue is holding back my automated trading in production.

Thanks

@dynamic3 Sorry for the delayed answer. It’s not clear to me who prints these information messages. There are no such messages in the .NET SDK code. Please, try to add exception type + call stack printing into the error handlers that print just an exception message right now.

@oleg.rakhmatulin it appears the connection is dropping after subscribing to 2100 symbols (trade/quote streaming) the broken pipe/connection reset by peer error is happening as i attempt to subscribe to the remaining symbols (trade/quote).

The remote party closed the WebSocket connection without completing the close handshake.

Is it possible to have simple way to SubscribeAll active for both Trade/Quote subscriptions instead of going 1 by 1? Seems the iterative way is causing the connection to drop

Of course, you can prepare a list of all symbols and subscribe to all of them using extensions methods GetTradeSubscription/GetQuoteSubscription from the Alpaca.Markest.Extensions NuGet package. These extension methods provide a way for creating the single subscription object for a list of symbols.

But in general - I’m not sure that problem is in the subscription process. Most probably server drops your connection because a client is unable to handle so much data. Receiving trades/quotes data for ALL instruments looks easy but it required a lot of network bandwidth and very fast client-side processing.

AFAIK on the server-side, some code checks how many messages are sent and how much is already consumed by the client. The speed of this message queue processing depends mostly on your network connection.

I’m on a 500Mbps dedicated, 64GB ram with Dual QuadCore running Linux. Is that too low? I will try to upgrade the speed to see if the issue presists.

@oleg.rakhmatulin same problem even with updated connection.

I need exact stack traces (not just messages) for all errors reported by the streaming client.

I’m unable to get the exact stack trace message because the connection just seems to be getting dropped without the onError event triggering. So I am a bit confused, could this have to do with the .NET 2GB limit?

errors:

Unable to write data to the transport connection: Connection reset by peer.
Unable to write data to the transport connection: Broken pipe.

@dynamic3 If these messages are not from the OnError event handler - how they are generated? Are they from .NET internals?

The 2Gb limit for max string size is not a problem here - Alpaca streaming never sends such big messages. Most probably root cause is inside the .NET web sockets subsystem. I’ll check it in the meantime.

Please, open a GitHub issue and provide all required information about this error - minimal code snippet for reproducing, Alpaca .NET SDK version, Linux distro name + kernel version, your target .NET version/bitness. If you can collect memory/CPU/network consumption data it also would be very helpful.

I believe this to be strictly C#.NET issue on the client side. I did a little test and tried to connect to all bars, trades, quotes using a alpaca-java library (GitHub - Petersoj/alpaca-java: A Java API for the commission free, algo friendly, stock trading broker "Alpaca" https://alpaca.markets) and I was able to connect and get data without a problem or connection issues… so I will have to rework my code to strictly java and get away from C# development altogether.