Topic: [BETA] MTGox websocket API, testers wanted - page 18. (Read 77653 times)

Hello all, developing in Java here.

Aiming at creating an interface similar to Trade Station's Matrix: http://www.tradestation.com/strategy_testing/market_depth.shtm

I'm using Open Office Calc as the front end.  I've got the real-time data flowing into calc nicely, but I've run into the same sync issues everyone else is having.

As others have done, I'm bootstrapping my depth info with http://mtgox.com/code/data/getDepth.php, but before long, none of the volume information makes any sense.

I'll be happy to share my source with any interested parties.  For now I'm going to put this on the back burner until a solution to the sync issue has been implemented.

I'll put my vote in for a channel that publishes absolute volume information in addition to some effective bootstrapping method.

+1 for wss://

Cheers,

it will be good create IRC-channel

• for talks
• for "websockets OFF for hour"
• for bans in websockets (if exists)

at now
opened socket, sent handshake, received nothing - conn reset by peer
and I dont know what happened and how long it will last

Here are some things I've noticed after building some web applications using the WebScokets API:

• Switching to the Secure WebSocket (wss://) would dramatically improve compatibility, especially for those behind a proxy
• Security would also allow users to send trades via the WebSocket, which would simplify trading to one connection instead of polling+WS.
• Send the prices and volumes as integers! Bitcoins are stored as integers in the client but displayed as floats by dividing by 1e8. Some of the prices and volumes quoted over the WebSocket are floating point numbers with much more precision than the 8th decimal, which doesn't make sense in the framework of Bitcoin overall.
• The ability to request the depth of market table entries through the WS
• More consistency in depth of market updates - I have to poll the data every so often in order to eliminate discrepancies, which is not very robust and could be misleading to people using my service.

I think the API shows a lot of promise, but it's seems to be missing one key detail --- without publishing an order-id on the depth message, and the constituent order-ids on the trade message, it's not really possible to ever get in sync.

The reason is as follows: if you start your connection and receive an order @ 25 for volume 10, and then there is a trade @ 25 for volume 5, you can't tell if the trade was for part of the order you just received, or an earlier order (pre your connection time).

If, however, you were to provide an order-id on the depth message, and the pair of order ids on the trades, then all ambiguity is removed.

is websockets down? any ETA?

thanks

Which min volume of order required for trading (min step size)?
I saw volume=0.007 in depth channel, but ticker channel ignores that values (so values lessOrEqual 0.007 I ignore)

hint (from my bugs)
see MSDN Math.Round( decimal d, int decimals ), which I use
MtGox rounds numbers NOT SAME:
If the value of the first digit in d to the right of the decimals decimal position is 5, the digit in the decimals position is rounded up if it is odd, or left unchanged if it is even. If the precision of d is less than decimals, d is returned unchanged. The behavior of this method follows IEEE Standard 754, section 4. This kind of rounding is sometimes called rounding to nearest, or banker's rounding. It minimizes rounding errors that result from consistently rounding a midpoint value in a single direction.

some datas:
{"channel":"24e67e0d-1cad-4cc0-9e7a-f8523ef460fe","depth":{"price":30.22425,"type":1,"volume":1},"op":"private","origin":"broadcast","private":"depth"}
{"channel":"d5f06780-30a8-4a48-a2f8-7ed181b4a13f","op":"private","origin":"broadcast","private":"ticker","ticker":{"buy":30,"high":31.89,"last":30,"low":18.6,"sell":30.2243,"vol":98781}}

Hi,
    The websockets API is *great*. I have a suggestions for the protocol:


The size in the depth messages should publish the new absolute size, not the relative size. Subscribers can still figure out the relative size change by subtracting from the previous update at that size, but this provides better error recovery on the client side.

I'm not sure it's been mentioned before, but the data type of the getDepth.php return does not seem to be application/json, so it is not possible to do a cross-domain call to MtGox for the depth of market data.

This would be a really easy and quick fix in the getDepth.php code...

Makes sense - I'll watch it. Thanks!

The ticker high and low are probably those respective prices for the current trading session, which I'm guessing is a full day. You should watch the ticker values for when the volume resets to zero, as that would be the beginning of the trading session.

This might be a stupid question but I dont fully understand the meaning of the ticker.php api.
It returns something like that:

{"ticker":{"high":7.51,"low":7,"vol":33895,"buy":7.257,"sell":7.3499,"last":7.2591}}

What exactly is high and low? the rest seems pretty clear but I am not sure about those two

good variant (1)
but people dont want to calculate depth state. they often will request the one. more traffic, slow server, bad trading.

variant (1.5)
every depth message contains all state. without unnessary attrs - one number is price, next in pair is volume with right sort order: "depth":{"asks":[X.XXXX, V.VVV,...],"bids":[...]}

another variant (2):
- new channel for depth-20(or some N) values asks & bids every one minute (only for checking purpose or as starting point)
- clear description of algorithm how calculate depth state over trade & depth channels

one more variant (2.5):
- depth values is absolute forever
- new attr "pos" with values { +N, N, -N } where
     +N - new row inserted at N pos, rows [N..end] shifted down
       N - updates values ar row N
      -N - row N deleted. other rows shifted to close gap (to up)
- "trade" values ​​must match the changes in "depth" values (a priori)
- but still need starting point - current depth state - use variant (2) or something
pros: simple calcs, asks & bids always sorted by server(that must be), traffic +1attr, CPU calcs almost same(as now)

"make your choice!"

now: values with volume less 0.001 remains in my depth state after process depth & trades from corresponding channels. but next ticker does not account for their. so, I delete them from calculated depth state.

I prefer my suggestion of a request packet which the client can send at any time to request the complete depth state, and then relative +volume -volume stream continues from there.


We need as many digits as people can specify, which as far as I know is an unlimited amount.

volumes and prices sometimes received as :X.YYYYYYYYYYY
who needed so many digits after dot?
for price enough.. 2 digits for cents.. and.. ok, let be 4digits after dot
for volume.. hmm.. similar numbers less than 0.001 are considered as zero.. = so 3 digits after dot for volumes

maybe
needs some authorization vs WebSockets' flood from bag guys (direction: from client to server)

something like this:
- some cookie received from Trade API for websocket connection to MtGox. this cookie valid only next hour (5-10-30min)
- on new connection to websocket client must send this cookie to server. if cookie is valid automatic subscribing will do..
cons: more difficult process for connection

or:
- using SSL/TLS encrypted WebSocekts.
pro: can refuse polling Trade API and do all orders and receive statuses over WS
cons: need implementations for different languages

imho
It will be good to send 10-30 best Sell and Buy depths one new connection after subsribe to depth channel : price, type, ABSOLUTE-volume
After that depth data sent in relative manner: +volume, -volume
It gives knowledge to robots(or men) of current volumes for asks & bids.

technically:
JSON changes to this: add new attr to "depth": "abs"=X: where X = "1" for absolute volume; "0" or absent attr - relative volume as now
That data can be cashed on server for all new clients. Depth changes updates cache. Need to generate JSON (for sent) on request only - more expansive operation than just update some structs in cache.

PS
Sorry for my Russian English

I wrote some code in C# for MonoDevelop or Visual Studio
MtGox & IMtGoxHandler & TestMtGox - for making orders
  FetchCash
  FetchOrders
  Place/CancelBuyOrder
  Place/CancelSellOrder
  .Handler - interface for responses & errors
WebSocket & Program - for read trades events
  .OnData - delegate received string (in JSON format) for any channel

https://rapidshare.com/files/3646016978/MtGoxApp.zip

Ah excellent, any information on the form of this new system?