[zeromq-dev] Java/Windows issues

[Steven McCoy]

2009/8/20 Robin Weisberg <robin at scout-trading.com>:
>>>    Additional sequence numbers on top of TCP/PGM are unaviodable for
>>>    guaranteed delivery (the one that survives component restart). As
>>>    you say, UDP is an option, however, it would mean reimplementing all
>>>    the nice TCP functionality (thing of congestion control mechanisms)
>>>    so I believe few additional bytes per message are worth of it.
>>>
>>> Congestion control is nice for point to point. Doesn't really apply much
>>> in multicast of course, just because one guy goes down doesn't mean anybody
>>> else is throttled.
>>
>> There've been some research done on the topic. I've personally liked the
>> PGMCC by Luigi Rizzo. The paper should be available on the web in case you
>> are interested.
>
> I'm sure there is a use case, I just don't think its the most common one.
> The major middleware vendors don't implement this as far as I know.

Actually they do, but depends who you consider major vendors.  Reuters
does on-top of Rendezvous with RRCP, and inside their own RRCPD.
TIBCO does with SmartPGM, but not with Rendezvous TRDP or PGM.  29
West does with LBM with functionality to also shut off clients that
are requesting too many retransmissions.

Many vendors also create tools for identifying problematic clients so
they can be programatically or manually shutdown and repaired.

I haven't implemented in OpenPGM yet due to lack of interested sponsors.

-- 
Steve-o