Comet Servers for a Single-Dealer Platform (SDP)


There is a lot more to a Single-Dealer Platform than just a Comet Server, but it is still a key component and often one of the components bought in rather than developed in house. At Caplin we have dedicated much of our time to building what we believe is the Comet server that offers the best performance and feature set on top for building a SDP. Hopefully this post will explain why we believe this, and where you might have more work to do with the other products.

A Comet server allows an SDP to deliver prices and manage trading between a backend system and a browser client – although many will support other clients too. These days there are a number of choices for a Comet server, and more of them are realising that financial data is a great use case and targeting effort in that direction.

Questions?

If you are choosing a Comet server for an SDP there are a number of questions you should be asking that will have a big impact on the amount of integration and other work you will have to do.

  1. What is the structure of the messages or objects?
  2. Does it support bidirectional messaging?
  3. Can it throttle or conflate fast updating data?
  4. What languages are client APIs available in?
  5. What languages are backend integration APIs available in?
  6. How does it perform with high numbers of users and update rates?
  7. How does it perform in terms of message latency?
  8. How does it integrate with permissions systems and Single Sign On (SSO) ?
  9. How much bandwidth does it use?

Cometdaily covers some Comet servers focusing on the low level technical details that relate to Comet specifically with their Comet Maturity Guide. This is important, however it doesn’t really help differentiate between the offerings for an SDP, and doesn’t really answer all of the questions posted above.

I have looked at a number of Comet servers over the last few years and the following information is based on what I have experienced when I tried them out. Where I have been unable to obtain information directly from trying them out I have acquired it from documentation and performance results published by the providers.

Liberator is of course a Caplin product and many, if not all, of the other servers may be perceived as a competitor in some way. I have tried with best endeavours to be impartial in my assessment but invite comments from all the mentioned vendors if they believe there are inaccuracies about their server, or if they feel I have misrepresented them


Caplin Liberator

Mature C based product focused on finance and trading (Integrates with higher level APIs in Caplin Platform)

Messages/Objects: Field/Value based record objects, plus higher level types such as lists of objects
Bidirectional: Yes
Conflation: Yes
Client APIs: Good – Javascript, Java, .Net, Silverlight, C, Flex
Server APIs: Good – Java, .Net, C/C++
Performance: Excellent (Published)
Latency: Excellent 1 (Published)
Permissions/SSO: Good – API based / SSO integration built in
Bandwidth: Excellent

Lightstreamer

Mature Java based product and finance aware.

Messages/Objects: Field/Value based
Bidirectional: Yes – in version 3.6
Conflation: Yes
Client APIs: Good – Javascript, Java, .Net, Silverlight, Flex
Server APIs: Average – Java, .Net
Performance: Good (Unpublished)
Latency: Good (Unpublished)
Permissions/SSO: Good – API based / SSO integration possible
Bandwidth: Excellent

Adobe LCDS

Limited to Flex clients. Not really focused on finance. Integrates well in areas outside of Comet.

Messages/Objects: Object serialisation based
Bidirectional: Yes
Conflation: No
Client APIs: Limited – Flex
Server APIs: Limited – Java
Performance: Average – better in Version 3 (Blog)
Latency: Good (Blog)
Permissions/SSO: Simple API based
Bandwidth: Poor 2

my-Channels Nirvana

Messaging server with lots of API support. Probably suits people with the enterprise/message queue/JMS mindset.

Messages/Objects: Opaque and Field/Value based
Bidirectional: Yes
Conflation: No – opaque messages
Client APIs: Excellent – Javascript, Java, Silverlight, Flex, .Net, C++, iPhone, Android, Blackberry/J2ME
Server APIs: Good – Java, .Net, C++, VBA
Performance: “many thousands” (Unpublished)
Latency: “ultra fast low latency” (Unpublished)
Permissions/SSO: Good – API / SSO integration
Bandwidth: Unknown

Kaazing Gateway

Kaazing Gateway is a WebSocket style server. It is intended to be used to bridge a client to an existing socket based server. This means it is missing many of the features of the other servers, but could be attractive to someone wanting a minimal server to build on top of.

Messages/Objects: WebSocket API only
Bidirectional: Yes
Conflation: No – opaque socket
Client APIs: Good – Javascript, Flex, Silverlight, Java
Server APIs: Socket interface
Performance: “millions of messages per second” (Unpublished)
Latency: “near zero latency” (Unpublished)
Permissions/SSO: None
Bandwidth: Dependant on application

Migratory Push Server

Relatively new product that scales to very high numbers of users. Background in RMDS, so finance focused.

Messages/Objects: Field/value based
Bidirectional: No evidence of bidirectional API
Conflation: Unknown
Client APIs: Average – Javascript
Server APIs: Average – Java, PHP
Performance: Excellent (Published)
Latency: Good (Published)
Permissions/SSO: Unknown
Bandwidth: Good – but still sends full topic and field names

Jetty/Cometd

The free alternative. There are plenty of other free Comet servers, but I chose to include Jetty/Cometd. This is the main server behind the Bayeux protocol

Messages/Objects: JSON message structures
Bidirectional: Yes
Conflation: No
Client APIs: Average – Javascript, Java
Server APIs: No specific server API
Performance: Average (Blog)
Latency: Long Polling only – not so good for fast updating data
Permissions/SSO: Simple API / SSO Integration
Bandwidth: Good – but still sends full topic and field names

Subscription semantics

One area not covered above is the subscription semantics. Most of the Comet servers here implement some kind of publish/subscribe model. This is implemented in a number of ways though. Pure pub/sub, as I think of it, de-couples producers and consumers completely and a when a consumer subscribes they only receive something the next time that item updates. In financial applications this can be quite limiting.

The first aspect of that, the de-coupling, is inefficient. You don’t want producers of data sending everything on to the next hop in the chain if noone is subscribed to it – it is better if the producer is told when to start and stop publishing for a specified topic. In a fixed income application there could be tens of thousands of instruments, but not all of them will be subscribed to at any one time. For pure pub/sub systems this extra layer of subscription handling is often implemented on top of the core functionality at integration time.

The second aspect is also often implemented as an after thought on top of a messaging system. When a subscription is made to a financial instrument, most of the time you want to see the current values (the image) and receive subsequent updates to those values. Systems that don’t implement this for you leave you open to nasty race conditions if you try and add a cache.

Performance

Performance and latency are difficult to compare directly. Even if a head to head bake off is setup, there are numerous variables involved in these kinds of tests, and some servers may fare better in particular scenarios but worse in others. For example Migratory have cleared put some effort into supporting very high numbers of users, something that we haven’t had the demand for at Caplin so our tests have only ever gone up to 30,000 users (which is still a high number for many financial use cases). For some scenarios squeezing out every last drop of latency is priority, whereas others need lots of users and high update rates and can accept a slightly higher, but maybe more predictable, latency.

For a lot of applications predictable latency can be more important than the latency itself. When a price is quoted, with a known latency to the recipients of that price, the latency can be taken into account to cover the risk involved. However, if the latency is unpredictable then the highest likely latency will have to be taken into account when a price is quoted. Alternatively it will be necessary to introduce a threshold that blocks trading on more latent prices, which doesn’t lead to a good user experience.

Conclusions

It is possible to build an SDP with any of these products, but there are two high level reasons why some will be better than others. Features and Performance. In most cases the features mean there will be a lot less work in building your SDP, but you could probably still do it given enough time and money. However, performance may be more of a stumbling block. You may be able to solve it by throwing more hardware at it, but often the nature the of problem is not perfectly scalable and you will still hit issues.

There are other aspects of Comet servers that can help with developing SDPs, I have concentrated on some key aspects that are comparable in some way and hopefully provided some useful information.


[1] The published Liberator benchmarks only show tests where batching was configured. This gives more headroom at the expense of latency. I have recently carried out some tests with zero or much lower batching to get the lowest possible latency with excellent results and without impacting the numbers of users/updates too much. These will be published along with a whole new set of benchmarks in a few weeks time.

[2] LCDS messages can be sent in a number of formats. One is XML based which means message sizes up to 10 times the size of the best here. Using AMF it cuts out XML tags, but still contains a lot of data, eg field names. Messages are still up to 5 times larger than the best here.

Related Posts with Thumbnails

24 Comments

  • Martin Tyler says:

    Matt’s comment on his blog – http://mdavey.wordpress.com/2010/05/05/comet-server-performance-whos-the-winner/ (link back above) mentions Stream – http://www.stream-hub.com

    StreamHub has been on my radar, but they haven’t really come up much yet.

    I’d welcome more vendors to publish performance results, as mentioned we’re just running some new ones ourselves at the moment, as are Adobe.

    I’d also be interested if Lab49 want to collaborate on running some tests, it can be time consuming though!

  • John says:

    How about getting http://www.stacresearch.com/ to produce “independent” benchmarks for streaming servers ?

  • Martin Tyler says:

    Hi John. Yes, that would be good. Testing Comet servers isn’t trivial due to the large numbers of clients needed, so specialised test harnesses (or tons of machines) are needed which means a fair bit of work to do it for a number of products.

    Maybe some kind of test and hardness spec could be written and vendors submit their own tools do the vendor specific stuff.

  • Paul Brant says:

    Paul’s sweeping attempt at classifying everything that might offer a realtime messaging capability via the Internet as Comet demonstrates a lack of understanding of the issues faced when implementing such multi platform streaming solutions for SDP. Comet, while relevant, in no way represents every product in this space, it simply (as the wiki link he included states) represents a number of techniques that enable the streaming of data from a server to a browser.

    Nirvana ( http://www.my-channels.com/ ) supports Comet ( and the WebSocket protocol )for our Javascript browser based clients however we do so much more than Comet for all of our other supported Enterprise, Web and Mobile clients.

    While the 9 questions Paul defines are relevant they are far from complete and although integration is mentioned in the prequel to the list it is subsequently glossed over. To establish a more complete list of discussion points to aid these types of technology decision one might also include:

    - Support for clustering and failover approaches this enabling compliance with business contingency policies.
    - Support for standards. Things like HTML5 WebSocket support, AMQP, JMS etc.
    - Support for integration with 3rd party technologies. Not just back end but client side integration for end to end B2B type solutions
    - Support for integration with existing enterprise management technologies. Measuring end to end latency is only possible if the underlying technologies used supports such functionality and expose it in administration and management API’s and tools.
    - Security, not just SSO but an understanding of authentication and entitlements and how such functionality can be leveraged in client implementations
    - Configuration management, both client and server. Snapshotting production environments, being able to roll back configurations and quickly deploy new instances.
    - Support for different messaging paradigms. Not everything fits into a publish/subscribe model. Some interactions require point to point or queue based communications.
    - Support for different deployment topologies, i.e broker and brokerless based servers, caching severs and server federation.

    Finally on the subject of performance in our experience clients pay little attention to vendor published results and always understandably insist on establishing what is possible in their respective environments; typically via a vendor bake off. To date Nirvana has proven to be very successful in these real world test case scenarios and consequently is used today by some of the worlds leading SDP implementations.

    Perhaps market share and implementation base should also be included in the questions to be asked !

    • Martin Tyler says:

      There is no lack of understanding here – re-read the start, I clearly state that an SDP is more than just a Comet server, but this blog is about Comet servers – since a lot of people DO think that a Comet server is all you need to develop an SDP. This blog is meant to show just a few things that might differentiate Comet servers, even though there is so much more around them when considering a whole SDP stack.

      I don’t think any of your points are wrong, but the blog was not meant to cover everything, it would need a whole series of blogs to do that.

      I think from your list I would pick out failover, latency and authentication/entitlements (although I thought I covered this, reading it back it doesn’t make it clear I was talking about more than just SSO)

      Finally on the subject of performance, in our experience clients pay a lot of attention to our vendor published results and many also want to run their own benchmarks (mainly because scenarios can differ so much) for which we provide a set of tools to do so with.

  • Paul Brant says:

    Please replace Paul with Martin although from memory PaulC feels the same

  • Ronen says:

    It’s an interesting comparison but it lacks the most significant factor every buyer needs to address…Pricing! There are HUGE differences between the products mentioned in terms of price models. Any comments?

  • Wonderful, what a weblog it is! This weblog provides valuable data to us, keep it up. archeage power leveling http://www.cheap-archeage-gold.com/archeage-power-leveling.htm

  • I think the admin of this web site is truly
    working hard in support of his web page, because here every material is quality based material.

  • Human Rights says:

    Hey! I could have sworn I’ve been to this site before but after reading through some of the post I realized it’s new to me.
    Nonetheless, I’m definitely happy I found it and I’ll be book-marking and checking back frequently!

  • The other day, while I was at work, my cousin stole my apple ipad
    and tested to see if it can survive a thirty foot drop, just so she can be a youtube
    sensation. My apple ipad is now broken and she has 83 views.
    I know this is completely off topic but I had to share it with someone!

  • I truly love your website.. Excellent colors & theme.
    Did you create this amazing site yourself? Please reply back as I’m hoping to create my very own website and want to find out where you got this from or what the theme is called. Thank you!

  • I think what you wrote made a great deal of sense.
    But, think on this, suppose you composed a catchier title?
    I am not saying your content isn’t solid, but suppose you added a title that makes people desire more?
    I mean Comet Servers for a Single-Dealer Platform (SDP) | Platformability
    is kinda boring. You could look at Yahoo’s front page and note how they create article headlines
    to grab people to click. You might add a
    video or a pic or two to grab people excited about what you’ve
    got to say. Just my opinion, it could bring your website a little livelier.

  • lolatoys.com says:

    Excellent post. I was checking constantly this weblog and I am impressed!
    Very helpful info particularly the last part :) I care for such information a lot.

    I used to be looking for this particular info for a
    long time. Thank you and best of luck.

  • Spot on with this write-up, I really feel this site needs a great deal more attention. I’ll probably be back
    again to read through more, thanks for the advice!

  • Good way of explaining, and nice article to get information about
    my presentation subject, which i am going to present in university.

  • Marcelino says:

    WOW just what I was searching for. Came heree by searching for harga pelangsing wmp

  • cute kitten says:

    Hi, I ddo believe this is an excellent site.
    I stumbledupon it ;) I’m going to return yet again since i have book-marked
    it. Mone andd freedom iss the greatest wway too change,
    may you be rih and continue to help other people.

  • titties says:

    I think that is among the such a lot important info for me.
    And i’m glad studying your article. However want
    to commentary on few normal issues, The site style is great,
    the articles is in point of fact excellent : D. Excellent activity, cheers

  • trello.com says:

    Then I hydrate a bit, and switch to some upper body stuff with particular interest to my rotatory cuff, which requires six separate workouts.

  • A man and a lady, irrespective of whether they are boyfriend and girlfriend, coworkers, or brother and sister,
    get started on the same weight loss path full with the exact same eating plan and the identical quantity
    of exercising.

Leave a Comment

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image