voeventnet.caltech.edu
Transporting VOEvents
Andrew Drake, Matthew Graham, Roy
Williams, et al.
GCN VOEvent prototype
Concept:

Modify Scott's socket_demo.c to send
VOEvents. Why?



GCN VOEvents should be sent from GSFC
without interruption.
Familiar code starting point.
Make a small client to send just VOEvents for
possible future switch to VOEvents alone.
GCN cont.
Code.
Transform GCN packets to VOEvents.

Write VOEvent xml string over TCP


Events can be sent with modified version GCN
socket_demo. No additional libraries. Single
function call. Or...
From a file with a small client.
Server to receive VOEvents

Acknowledge receipt to client

Creates a Webpage with event links


RSSfeed
DataScope link
Possible Problems






Errors. Limited error checking (include a
hash).
Security. Events sent as plain text.
Delays. Many subscribers/events could
cause connection delays.
Lost notices. Currently single socket
connection.
Data content needs to be checked for
errors.
What about GCN circulars as follow-up
VOEvents?
A Second Approach


Send converted GCN packets over Jabber
Jabber XMPP


An open, secure, decentralized, and
extensible IM service.
Client-Server (email like) arch but aware of
user presence.





Presence connected (listening, ignoring), not
connected, do not disturb.
Clients connect with TCP (socket 5222 or 5223)
C2s one-way XML stream, s2c separate stream
Messages sent as XML snippets (stanzas).
Each user unique JID node@domain/resource.
PubSub (JEP-60)


~80 Jabber clients and 15 server code
library sources available (most GPL) in Java,
C#, PHP, C, C++, Python, Perl, etc.
However, plain IM lacks subscription thus not
suitable for sending events.
Jabber Enhancement Proposals


Increase functionality via:
Message logging, jabber to email, HTTP-polling,
HTTP-binding, service discovery, file transfer, etc.
Publish Subscribe for Jabber (JEP-60).

Broadcasting of event notification for authorized
subscribers.
PubSub Cont.








Server mediates connections.
Publishers send data to node
Servers can keep record of sent events
Affiliations to, subscribe, publish, purge items,
config a node, delete a node.
Users can be publishers, subscribers, or blocked.
Message nodes can be discovered by clients.
subscription can be open, list, authorized.
Message nodes can be configured with persistent
items, deletion, retraction, change notification.
PubSub Cont.

Errors


Security


Stream errors (such as <xml-not-well-formed/>,
<bad-format/>,<connection-timeout/><notauthorize/>, <remote-connection-failed>)
handling in XMPP core (but errors within
message xml possible.
Core protocals include end-to-end signing and
object encription via TLS and SSL.
Delays

Jabber servers can cope with thousands of
concurrent users sending instant messages.
Problems using Jabber.





Few servers with PubSub support modules.
Only single commercial venture
(PubSub.com). However, 200,000+ current
users.
Few clients understand pubsub iq stanza
messages (though messages are simple to
handle).
JEP-60 still a draft after 2+ years (like most
JEPs).
Aggregation?
VOTimeSeries
Why do we need timeseries data for VOEvents?




Services like DataScope are fine for one-off
events (GRBs, supernovae).
Recurring variable objects (QSOs, variables
stars), microlensing events, etc, need timeseries
to distinguish between real objects and artifacts
(cosmic rays, ...).
Many large scale legacy timeseries datasets
already exist (Macho, EROS, OGLE, Quest1,
LONEOS, ROTSE, etc) but are either not
available or are not being utilized.
Many more will come ... LSST, SM, Essence,
Palomar-Quest, PannStars.