Launch of our new Multicast service

As of Wednesday 13 April 9 AM UTC Deribit will activate a development feed for Deribit’s new Multicast service.

This new service is only available for colocated or cross-connected clients in Equinix LD4 and not for clients connecting via the internet (as multicast over Internet or public networks in general has never been implemented). Deribit is the first crypto derivatives exchange to offer Multicast.

What:

• The events are sent in UDP multicast packets using the SBE (Simple Binary Encoding V1) format.
• Deribit Multicast is optimized for low latency encoding and decoding while keeping bandwidth utilization reasonably small.
• A LUA Wireshark dissector plugin has been created that allows Wireshark packet capture/analysis tool to display the content of the multicast packets.
• Deribit will not charge a fee for this new feed.
• Please find a SBE decoder for dev purposes here.

When:

• Deribit will activate Multicasting as a development feed on channel 10 and 110 (USDC Perpetual production data) Wednesday 13 April at 9 AM UTC.
• The production launch of the full feed (all instruments) depends on client feedback but is aimed to be launched before the end of the month.

Who:

• The feed will be made available to all clients connected to Deribit in Equinix LD4 which includes colo clients and cross connected clients. The colo clients are getting the multicast feeds by default (without doing an IGMP join), however the crossconnected clients do need to do an IGMP join on the relevant multicast groups. We’re looking into integrating it into AWS as well, but that will not be available from the start.
• Whether the third party, such as Beeks or UltraFX, cross-connected clients can use the solution depends on the ability & willingness of the connectivity solution provider.
• In case colo clients do not want to receive this feed over their network, they can request deactivation by mailing [email protected] using their registered email and confirming the server’s IP address.

FAQs

An instrument ID filed has been added to map instrument name with the UDP message. Will this instrument ID change for a same instrument?
No, instrument ID won’t change for the same instrument

In the spec it recommends client to use the “public/getorderbook” to get the iniital order book and to join it with the buffered UDP event messages. However there is also UDP snapshot channel being introduced. Can client also use this snapshot UDP channel to get initial order book?
Yes, snapshot multicast is also meant to build initial data. However the change buffering should still be done, since during the gathering of snapshots and sending them out in a batch it is possible to have a change. This duration depends on the number and depth of instruments on a channel, however generally not expected to take longer than few hundred ms.

In the xml message protocol it uses double for price and amount fields. However SBE official doc. recommend using decimal for such price and amount field if they need involving fractional value.
Indeed. However as the comment in the XML spec also mentions, the decimal format makes sense when the position of the decimal point is more or less fixed. In our case it may vary more than at traditional exchanges, based on currency pair and instrument type.

How will the new Multicast feed be delivered to the end devices? What network protocol will be used? PIM?
Client will have to send a IGMP join, or Deribit can statically join client (our preference goes to the first). Deribit will not use PIM, so client is free to setup their RP by themselves in the path to Deribit.

Multicast network side config – does Deribit use dense mode or sparse mode on network side to forward the multicast data?
Advertisement of the source of the multicast is done through BGP and falls in the /24 public ip space that Deribit is advertising. You need to do a IGMP join on the P2P interface to receive the multicast feed, so you could configure the RP on your own router that is in the path to Deribit.

Does Deribit use Dense or Sparse mode?
Dense en Sparse are based on PIM which is not supported in our setup.

How to check connection is succesful?
Clients can you check if the join has worked on the machine with command : ip maddr
If you see the multicast address assigned to the right interface, then join worked and that part of your code is ok.
if join worked, client could use : tcpdump -i port 6100 to check if anything comes in. If you don’t see Deribit would need to check network

Is it correct to assume that changeId in the snapshot will be equal to changeId of last OrderBook update (assuming no drops)?
Not necessarily. Collecting shapshots is independent from the events happening in the book. Since we obviously can’t (and don’t want to) hold up the events until snapshots are sent and potentially processed, It may happen that during the snapshot collection/sending/processing (on the client side) the client may receive/process a book event that’ll be “ahead” of the snapshot. This is why it is recommended to queue book events a bit before the expected snapshots.

Supporting vendors

Avelacom
Website: Link
Email: [email protected] – [email protected]
Telegram: @alinakarpichenko

Beeks
Website: Link
Email: [email protected]

ROQ Trading
Website: Link
Email: [email protected]

UltraFX
Website: Link
Email: [email protected]

BSO
Website: Link
Email: [email protected]

Trading Technologies
Website: Link
Email: [email protected] – [email protected] – [email protected]

AUTHOR(S)

RECENT ARTICLES