n0mad01
Bittrex WebSocket API Question
In another recent issue that has been closed (https://github.com/n0mad01/node.bittrex.api/issues/23), Ilya provides the following code sample for reading market data from the Bittrex WebSocket API:
bittrex.websockets.subscribe(['BTC-NMR'], function(data) { if (data.M === 'updateExchangeState') { data.A.forEach(function(data_for) { console.log(data_for); }); } });
However, I also receive websocket data where (data.M === 'updateSummaryState'). Can someone please advise on what 'updateSummaryState' means? Do I need to process these to keep my order book accurate or do I only need to process the 'updateExchangeState' packets?
Thanks for any help, Tom
updateSummaryState, this is for updated ticker. Whenever bittrex has updated ticker, you will receive message.
https://github.com/n0mad01/node.bittrex.api/files/1104308/WebSocketAPI_MarketTracking.docx Checkout this document.
No so clear yet. updateExchangeState and updateSummaryState are the only two messages bittrex websocket publishes? It would be nice know all the messages with the information of data that can be subscribed. Thanks.
Those are the 2 messages their websocket publish. UpdateSummaryState will send you the all the basic ticker information when updates are available. updateExchangeState will send you the "specific ticker" you subscribed. The push alert includes orderbook changes, filled orders. Check the document I posted above.
trade Id is present in the public REST API, but not in the websocket subscription. Websocket only has Nounce Id which is different from trade Id. Do you know it was designed as such. Is there any limit on how many times public API can be polled a second? Thanks.
websocket
{
"H": "CoreHub",
"M": "updateExchangeState",
"A": [{
"MarketName": "USDT-NEO",
"Nounce": 414329,
"Buys": [{
"Type": 0,
"Rate": 32.12379609,
"Quantity": 1.38254959
}],
"Sells": [{
"Type": 2,
"Rate": 38.7,
"Quantity": 1.00517096
}],
"Fills": []
}]
}
https://bittrex.com/api/v1.1/public/getmarkethistory?market=USDT-NEO
{
"Id": 4128276,
"TimeStamp": "2017-10-02T13:40:40.92",
"Quantity": 83.02424203,
"Price": 35.05,
"Total": 2909.99968315,
"FillType": "FILL",
"OrderType": "SELL"
},
@nengine I'm having the same annoyance. Bittrex will block you if you send too many requests, my less than optimal workaround is to use the Nounce and append to it the position of the fill in the array returned by Bittrex - assuming (probably wrongfully so) that it will be the same across multiple websocket connections.
Yes, good to know I am not alone. It would be great if Bittrex could add trade_id to websocket feed like it does on public API, but I guess they don't really care.
We've been waiting for Bittrex to add a trade_id to their websocket feed for many months now so as to put this code into production on Coinigy. Countless conversations with Bill, some of their new staff, tweets, you name it, and we're still unfortunately left waiting. Feeling your pain over here!
Hello I read the document in word and I could see there is an example using C# anyone knows where I can find the example? Thank you!
@RikardoPons it doesn't show up as an embedded document to you? I was able to navigate through to the C# example code. Here's the pastebin of the contents: https://pastebin.com/nrSLPqAv
Though, as I've commented in another issue, I'm having a problem with the example - attempting to query exchange state eventually errors out with "There was an error invoking Hub method 'CoreHub.SubscribeToExchangeDeltas'."
@kbahr It took me two evenings to figure out what was causing the There was an error invoking Hub method ... issue. After inspecting the stream using a sniffer I found out that SignalR was falling back to something called Server Sent Events instead of Websockets. That doesn't work well with this API. I'm still not sure why this happens, but I do know it only happens when using .NET Core.
When switching to .NET Framework 4.6 everything started working as expected, using the exact same code and SignalR package. There must be some underlying tech. that's not supported in Core yet.
@Grepsy thanks for the tip, but unfortunately it didn't clear up my issue :) I switched to LINQPad5 which uses .NET 4.6 and rebuilt the SignalR client library fresh (v2.2.2) just in case but still get the same error with the canned example.
It would be really nice if there were a straight websocket implementation or guidance on how to do that - not to be a luddite but what's with all this new fangled SignalR!? ;)
Hm, that's unfortunate. Maybe try with VS? I can sent you my client project which works for me. I remember I also installed this Windows package (although it seems server only, worth a shot), maybe that helps. See http://danielhindrikes.se/windows-8/enable-websocket-protocol-in-iis/
That's very generous, @Grepsy . I found a work around (one can specify the transport in the HubConnection.Start(...) call and I passed a WebSocketTransport) but I'm still very curious what I'm missing. If it's not too much trouble, I would like to see your working client and try to find the gap between that and my LINQPad script. I'll also try it it VS in the meantime.
This is my current impl. which works in VS2017 on .NET 4.6.1.
https://gist.github.com/Grepsy/3d080ff7cd61782dec42ffc213309122
Hope it helps!
@ale316 you were correct in your skepticism. Nounce is not the same across websocket connections making it all but useless as unique but consistent ID. 😡
come on BTRX add trade_id to websocket feed it is not like it is hard to do :-)
Has anyone found that one cannot ask for too many markets of data concurrently? I get data just fine now but only for a single market. If I ask for multiple markets, I just get nothing back.
you have to have a delay before subscribing to each market BUT with each additional market you subscribe to the number of missed messages increases. CATCH 22
Oh... well I guess I can live with being eveeentually fired up - any idea what the minimum delay is? I tried a few iterations of 1, 5, and 10s between.
I use 250ms and every 10 I take a 2s break. You are going to eventually run into bigger problems than just the timing once cloudflair kicks you
Oh? I wasn't going to hammer the REST API, just subscribing to the streams - they have a problem with that too?
the ws endpoint goes through cloudflair, eventually you will hit the ddos check from cloudflair which can not easily be bypassed
Subscribing to the streams happens trough the WebSocket connection, right? Does Cloudflare actually inspect the individual websocket frames and understand SignalR? I believe that once the connection is setup that should be opaque to Cloudflare. The REST API is another story indeed.
correct cloudflair does not inspect WSS, you will hit it during negotiation
this package will not be maintained, please switch to: https://github.com/dparlevliet/node.bittrex.api
Thanks for the link @n0mad01 ! As it happens, I am "rolling my own" but this issue seemed to touch on an issue I was having which I suspected was my interaction model or on Bittrex's Side.
@ByronAP what do you mean "during negotiation"? Assuming I establish my connection to the proxy, then trickle in messages, those should be just going as packets over an open connection shouldn't they? Does it renegotiate every message?
What is "type" in sells and buys? and How to determine that an order cancelled to update orderbook data?
