ZeroMQ vs Crossroads I/O

Question

Sto cercando di utilizzare ZeroMQ come livello di messaggistica/trasporto per un sistema distribuito abbastanza grande, principalmente per il monitoraggio e la raccolta dei dati (molti produttori, alcuni consumatori).

Per quanto posso vedere ci sono attualmente due diverse implementazioni dello stesso concetto; ZeroMQ e Crossroads I/O, quest'ultimo è un fork di ZeroMQ (nel 2012?).

Sto cercando di capire quale usare e mi chiedo delle differenze tra di loro, ma finora non ho trovato molte informazioni a riguardo.

Ad esempio:

• sono compatibili sul filo?
• Sono API compatibili, ovvero un tipo di API di base comune, eventualmente con componenti aggiuntivi diversi?
• Entrambi implementano il supporto per ZMTP (ZeroMQ Message Transport Protocol)?
• Condivide una sorta di comprensione comune dello sviluppo futuro o continueranno in due direzioni separate e possibili diverse?
• Quali sono i pro/contro in relazione all'altro?

In pratica, come si fa a scegliere l'uno sull'altro?

Answer 1

Crossroads.io è piuttosto morto in quanto Martin Sustrik ha cominciato su un nuovo stack, in C, chiamato nano: https://github.com/250bpm/nanomsg

Crossroads.io non lo fa, per quanto ne so, implementare ZMTP/1.0 né ZMTP/2.0, ma la sua propria versione del protocollo.

Nano ha trasporti collegabili e probabilmente effettueremo un trasporto ZMTP per questo. Nano è davvero bello, un ripensamento della libreria libzmq originale, e se riuscisse sarebbe un buon nuovo kernel.

Idealmente, Nano interagirebbe sia a livello di API che a livello di protocollo, quindi sii un sostituto collegabile per libzmq. Tuttavia, ha una lunga strada da percorrere.

Si noti che ora esistono diverse riscritture di libzmq che emergono, tra cui JeroMQ (Java) e NetMQ (C#). Questi due implementano correttamente ZMTP/1.0 e ZMTP/2.0. Ci sono anche altre librerie come Axon (https://github.com/visionmedia/axon) che sono fortemente ispirate da 0MQ ma non compatibili.

Sulla base dell'esperienza, gli utenti valutano l'interoperabilità più di qualsiasi altra cosa, quindi è molto probabile che diversi stack di tipo 0MQ finiscano per parlare gli stessi protocolli.