Quote from: martin on May 23, 2011, 02:08:23 PM

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.

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!"

Quote from: martin on May 23, 2011, 02:08:23 PM

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

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.