0MQ: The Intelligent Transport Layer

[Rob Seaman]

Hi Bob,

I can't comment on either your head or wall :-) but nothing is wrong with either the transport note or Dakota.  And however simple zeromg is, it certainly can't be simpler than vanilla TCP.  My suspicion is that vTCP and thus Dakota will be supported indefinitely, but that more boutique protocols like zeromg, elvin, Java messaging - and perhaps jabber - will come and go.  As has been said before, this implies the creation and maintenance of bridges in the deployed VOEventNet for any future network.  VOEvent itself is transport neutral by design.

Will vTCP scale to the current LSST baseline of two million alerts per night?  Will other technologies?  In the near term, projects now nearing completion or in commissioning will deliver many thousands of events nightly in the next few years.  These several surveys are each likely to produce numerous streams of events, filtered or correlated in scientifically interesting ways.  Registries - either explicitly through the VO or implicitly through the diverse stakeholders for each survey - will be used to discover streams and associated metadata and per-project schemata (again, either explicit or implicit).

All of these issues and the related science requirements from the diverse event-producers and consumers will have a hand in evolving the deployed infrastructure needed to scale to the future event rates and large numbers of future subscribers of different sorts.  There are a lot of different options for how that infrastructure will be funded and operated.  It is quite likely that different parties will provide access to different classes of subscribers as well as classes of event authors (both humans and autonomous agents).  For instance, I would think it an almost foregone conclusion that your customers would most robustly and efficiently subscribe through your software, whatever the network topology of future event brokers.  Whether one or more of those brokers includes bridging capabilities from some yet-to-be-specified transport protocol to vTCP seems (at this end) to be an implementation detail.

Or alternately, perhaps the native protocol of the event backbone will remain vTCP and no bridging will be needed by Dakota clients, but other subscribers will choose some trendy boutique notification service using either a push or pull paradigm.  Whichever it is, I would be flabbergasted if the astronomical community in general or IVOA in particular sought to forbid boundary components of the ramifying VOEventNet from including bridging technology to zeromg or any other transport protocol.

Rob
--

On Dec 26, 2011, at 9:08 PM, Bob Denny wrote:

> Magic Question: What is wrong with 
> 
> http://www.ivoa.net/Documents/Notes/VOEventTransport/
> 
> and 
> 
> http://www.ivoa.net/Documents/Notes/DakotaBroker/
> 
> (which is also a sender and a receiver that is cross-platform)
> 
> ?
> 
> Did I bang my head against the wall for the THIRD time since 2006???
> 
>   -- Bob
> 
> Roy W:
>> 
>> As we continue to wrestle with VOEvent transport, new (and simpler) 
>> protocols arrive. This looks promising ....
>> 
>> http://www.zeromq.org/
>> 
>> Anyone have any experience with this?
>> Roy
>> 
>> ---
>> Caltech LIGO
>> roy at caltech.edu
>> 626 395 3670
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20111226/97003e8f/attachment-0001.html>