3 ms·

Messaging in the financial sector has very different requirements from messaging for a general service backend, which I assume is what the OP is referencing. As

Messaging in the financial sector has very different requirements from messaging for a general service backend, which I assume is what the OP is referencing. As an example, a certain ecommerce site back in the day was heavily tibco based and migrated off due to inefficiencies at scale, multicast storms, debugability, and the general nature of multicast failures (for the most part you get no graceful degradation - which is fine when you have tight control of the network and do careful capacity planning, but isn't the mode that most tech companies live in). Anecdotally, non-multicast setups are easier to scale in hardware (because you can push commodity farther) and most critically are easier for the normal type of engineer you'd find in the tech sector to reason about (because many aren't comfortable with networking equipment, so it's much easier moving that state out of the network and into layers they can easily debug).

sseveran 10y ago
If its the same ecommerce site I am thinking of, then there was also non-trivial message loss.
otterley 10y ago
I worked on such a site in the mid-2000s. TIBCO Rendezvous was extremely efficient in the steady state, but boy, it had a catastrophic failure mode: during network congestion or receiver saturation, it would start repeating messages, causing the network congestion and saturation to worsen. The only way to stop the bleeding was to shut everything down. At any rate, most cloud SDNs don't support IP multicast (unless you use an overlay like Weave), so it's sort of a nonstarter for them. These days I might use Redis pub/sub along with a multi-level cache (e.g. LMDB + local Redis + remote Redis) if I need to distribute data to a large number of clients efficiently.
- tptacek 10y ago
  This is my experience with Rendezvous as well. The very largest financial organizations using Tibco tend to have a whole group of engineers whose only job is to keep Rendesvous from throwing a rod. Their networks are also overprovisioned and their traffic rates are pretty straightforward to characterize. You can, of course, use Rendezvous without multicast. And: does anyone still use it? The last exchange I worked with that did was migrating from it to JMS (which sort of gives lie to the idea that Rendezvous's multicast performance was that big a deal).
  - otterley 10y ago
    Back in the 1990s and early 2000s, network bandwidth and server capacity was a lot lower, so IP multicast was the most efficient way to distribute data to hundreds or thousands of clients. Now that 10Gb+ is commonplace and modern servers can service hundreds or thousands of message bus consumers with efficient kernel-managed event loops, yes, it's arguably less needed now. But nobody will claim it's efficient from a network perspective. :)
    - tptacek 10y ago
      Depends on what you mean by "from a network perspective". Bandwidth? Sure. Network processing? Not so much: multicast is expensive for routers.
  - deleted 10y ago
    [deleted]
  - SEJeff 10y ago
    Most financial firms (HFTs like I work for at least) purged Tibco with scorn and hellfire long ago due to reasons like the ones you just mentioned.
    - polskibus 10y ago
      What did they replace it with?
      - SEJeff 10y ago
        Non-open source proprietary systems, as one does :/
        kasey_junk 10y ago
        https://github.com/real-logic/Aeron https://github.com/real-logic/Aeron Is well regarded & open source
mrchicity 10y ago
By general service do you mean a system where response time isn't especially important? Using TCP to fan-out messages in a PubSub pattern is going to waste network and compute resources in a serious way. It can easily exhaust capacity or result in convoluted, unreliable systems with layers of proxies for managing load. FWIW when you talk about different requirements, I'm not sure you're correct. For traders, sure, oftentimes they can just dump old data if they fall behind because it's mostly irrelevant. However, stock exchanges have performance and reliability/availability as top requirements. They must record all transactions and can't crash or lock-up. Most use multicast internally and externally. They would never be able to scale and maintain a low response time with TCP.
deleted 10y ago
[deleted]

sseveran 10y ago

If its the same ecommerce site I am thinking of, then there was also non-trivial message loss.

otterley 10y ago

I worked on such a site in the mid-2000s. TIBCO Rendezvous was extremely efficient in the steady state, but boy, it had a catastrophic failure mode: during network congestion or receiver saturation, it would start repeating messages, causing the network congestion and saturation to worsen. The only way to stop the bleeding was to shut everything down. At any rate, most cloud SDNs don't support IP multicast (unless you use an overlay like Weave), so it's sort of a nonstarter for them. These days I might use Redis pub/sub along with a multi-level cache (e.g. LMDB + local Redis + remote Redis) if I need to distribute data to a large number of clients efficiently.

tptacek 10y ago
This is my experience with Rendezvous as well. The very largest financial organizations using Tibco tend to have a whole group of engineers whose only job is to keep Rendesvous from throwing a rod. Their networks are also overprovisioned and their traffic rates are pretty straightforward to characterize. You can, of course, use Rendezvous without multicast. And: does anyone still use it? The last exchange I worked with that did was migrating from it to JMS (which sort of gives lie to the idea that Rendezvous's multicast performance was that big a deal).
- otterley 10y ago
  Back in the 1990s and early 2000s, network bandwidth and server capacity was a lot lower, so IP multicast was the most efficient way to distribute data to hundreds or thousands of clients. Now that 10Gb+ is commonplace and modern servers can service hundreds or thousands of message bus consumers with efficient kernel-managed event loops, yes, it's arguably less needed now. But nobody will claim it's efficient from a network perspective. :)
  - tptacek 10y ago
    Depends on what you mean by "from a network perspective". Bandwidth? Sure. Network processing? Not so much: multicast is expensive for routers.
- deleted 10y ago
  [deleted]
- SEJeff 10y ago
  Most financial firms (HFTs like I work for at least) purged Tibco with scorn and hellfire long ago due to reasons like the ones you just mentioned.
  - polskibus 10y ago
    What did they replace it with?
    - SEJeff 10y ago
      Non-open source proprietary systems, as one does :/
      - kasey_junk 10y ago
        https://github.com/real-logic/Aeron https://github.com/real-logic/Aeron Is well regarded & open source

mrchicity 10y ago

By general service do you mean a system where response time isn't especially important? Using TCP to fan-out messages in a PubSub pattern is going to waste network and compute resources in a serious way. It can easily exhaust capacity or result in convoluted, unreliable systems with layers of proxies for managing load. FWIW when you talk about different requirements, I'm not sure you're correct. For traders, sure, oftentimes they can just dump old data if they fall behind because it's mostly irrelevant. However, stock exchanges have performance and reliability/availability as top requirements. They must record all transactions and can't crash or lock-up. Most use multicast internally and externally. They would never be able to scale and maintain a low response time with TCP.

deleted 10y ago

[deleted]