[vsnet-grb 170180] A GCN VOevent server is available

[Bacodine]

TO:  All GCN Notice recipients
RE:  A GCN VOEvent server is available
DT:  09 Mar 2012


INTRODUCTION:
GCN is now directly distributing GRB and Transient Notices in the VOEvent format
using its own servers (using the TCP/IP form of the VOEvent transport protocol).
GCN has been producing VOEvents for ~3 years, and they have been distributed
via a GCN-custom TCP socket method (and via re-distributors: NOAO, Exeter,
and most recently via Skyalert[1]), but now GCN has added the ability
to distribute directly to the world from its own servers.
People wanting to receive VOEvents using the vTCP VOEvent protocol
can subscribe to GCN VOEvent servers.

For the rest of this announcement, "client" and "site"/"subscriber"/"customer"
are effectively the same thing.  The VOEvent server program is called votan:
"vo" for VOevents and "tan" for the Transient Astronomy Network.
GCN is in the process of transitioning into a new name to better represent
the broader scope of transient sources that GCN has been increasingly doing.[2]
 
MOTIVATION and IMPLEMENTATION:
The NASA-GSFC IT Network security does not automatically allow[3]
for incoming connections through the Goddard firewall.  (The original GCN
socket connection method uses the reverse method: GCN is the "client" end
connecting to your site's "server" end.  Outgoing connections are always allowed
through the Goddard firewall.)  So, for this true server operation,
I have bought services on 3 different cloud companies, installed the votan server
program on them, and set up links between the GCN/TAN main program inside Goddard
to these votan programs.  (GCN is now thinking outside the box.)

DEMONSTRATION CLIENT PROGRAM:
To facilitate quick and easy connection to this new service,
a demo client program (voevent_client_demo) is available.
It can be downloaded from 
    http://gcn.gsfc.nasa.gov/gcn/voevent_client_demo.c
This GCN/TAN client is a clean, simple, standalone client written in C.
It needs no additional libraries or other software packages installed
on your system.  It has the basic parts to (a) establish and maintain
a connection to a server, (b) receive and acknowledge VOEvents, and
(c) tell you when there are problems.

CONNECTION PROTOCOL:
A connection between the client and a server is done using the so-called
"vTCP" protocol.  It is the standand TCP protocol with a "v"OEvent adjustment
involving (a) Imalive packet exchange, (b) a 2-part writing/reading action, and
(c) the explicit ack/nacking-ing of the VOEvents received.  The imalives
allow for both ends to monitor the vitality of the end-to-end connection,
and take corrective action if nothing has been recevied within 2or3 
of the 60-sec intervals the imalives are sent.  The 2-part writing/reading
starts with a 4-byte quantity sent first that indicates the length of the VOEvent
message that will be sent next (so the client reads 4 bytes, then knows
how to read to get the message).  The acking/nacking allows the server
to keep track that the client has correctly received the full VOEvent message.
The TCP/IP VOEvent protocol is described in
    http://www.ivoa.net/Documents/Notes/VOEventTransport/ .
If you already have a client which implements this vTCP protocol,
you can use it to connect to the GCN/TAN VOEvent servers.
(The voevent_client_demo is just a bare-bones example to get people started
if they have no prior experience with VOEvents.  You can also use
voevent_client_demo to connect to other VOEvent servers using the vTCP protocol.)

SERVERS AVAILABLE:
It is very easy to connect to a votan server.  There are 3 GCN/TAN servers:
    209.208.78.170    (on Atlantic.net cloud service)
    50.116.49.68      (on Linode.com cloud service)
    68.169.57.253     (on eApps.com cloud service)
They are all listening on port 8099.  So to run this demo, the commandline is:
    voevent_client_demo  <ip_num>  <port_num>
example:
    voevent_client_demo  209.208.78.170  8099

SERVER DUPLICATION/REDUNDANCY:
All 3 GCN/TAN servers listed above (and any others that might be brought
on-line in the future) have identical streams of VOEvents.  So connecting
to any single server will provide you with the 100% full content
that GCN/TAN produces.  And since all 3 servers use identical "sites.cfg" files,
registered users can switch from one server to another without any further
effort needed on their part or GCN's part, and of course, anonymous users
can also switch servers.  Software upgrades to the servers will be done
one server at a time -- the other 2 servers will always be running
so as to provide continuity.  (Software upgrades will take a server off-line
for about 90 sec.)

NOTICE FORMAT:
The messages are distributed in the IVOA VOEvent format,
which is described in
    http://www.ivoa.net/Documents/cover/VOEvent-20061101.html .   [Ver 1.1]

NOTICE TYPES AVAILABLE:
All of the currently available Notice types (59 of them[6]) within GCN
are also available from these servers.  (And when new Notice types
are added to GCN/TAN, they will automatically be added to votan servers).

FILTERING:
Even though votan is a server and you can connect anonymously[4],
if you register with GCN/TAN, you can receive all the regular
filtering capabilities of the original GCN system.
Votan is able to accomplish this by checking your IP Number (IPN)
when you connect.  If your IPN matches an entry in the votan sites.cfg file,
then it uses that configuration to determine which Notice types
you want to receive plus all 16 filtering rules.
(See  http://gcn.gsfc.nasa.gov/gcn/tech_describe.html#tc25
for a list of all the filtering functions available.)
If you register, you can have only one client running on the specified
machine (ie the IP Number), because votan uses only the IP Number
to identify you (ie no additional port_number like in original GCN).
Two clients on the same machine have the same IP Number.
Registration is simple -- a 'configuration' is built using the same
GCN config_builder webpage (see below).
If you choose not to register with votan, there can be no filtering
so then your connection will receive all Notices of all the types
(currently ~2000 per day; this does not count the 1440 imalive
transport-protocol messages sent per day).

SEE ALSO:
GCN has been distributing VOEvents using its own GCN-custom protocol
(also TCP/IP-based) since June 2009.
Information can be found at
    http://gcn.gsfc.nasa.gov/tech_describe.html#tc17
And for the email-based VOEvent distribution:
    http://gcn.gsfc.nasa.gov/tech_describe.html#tc18a
These 2 distribution methods will continue (to support existing customers).

ACTION ITEM:
a) If, after reviewing the information above/below, you want to receive
the GCN/TAN VOEvents, you need to decide if you want to have the filtering 
capabilities or not.  If you want filtering, then go to:
    http://gcn.gsfc.nasa.gov/gcn/config_builder.html
and select "#1 Create a new config" specifying the "VO_EVENT" selection
in the Distribution method pull-down menu (plus making selections for all
the other items that make up sites's configuration); 
or select "#2 Modify an existing config" and (at the least) change your current
distribution method to the VO_EVENT method. 
Of course, if you do not want filtering, then you can just connect anonymously[5]
to the server and receive all Notices the GCN/TAN produces.
b) Then you need to get a client (either voevent_client_demo or another client program)
and connect to one of the VOEvent servers listed above.

THE FUTURE:
The following items/functions will be implemented in the future
(in semi-prioritized order):
a) Adding VOEvents in Version 2.0.  (The GCN VOEvents are currently
   in Version 1.1.)  It is undecided if VOEvents1.1 will be maintained
   or be discontinued within GCN/TAN -- I would greatly appreciate ypur input.
   Version 2.0 is described here:  http://www.ivoa.net/Documents/VOEvent/20110711/
   A recent non-thorough survey of producers of publicly available VOEevents
   shows that only about 25% are in Version 2.0 (the rest are 1.1).
   Your input about usage of 2.0 VOEvents and availability would be appreciated.
b) Add capability for authors to publish to these servers.
c) Allowing anonymous connections to publish.
d) Having a database of past VOEvents that is queriable.




Sincerely,
Scott

Scott Barthelmy                      NASA-GSFC, Code 661, Greenbelt, MD   20771
PHONE:  301-286-3106                 (office)       CELL:   301-346-3733
EMAIL:  scott at lheamail.gsfc.nasa.gov
PAGER:  3013463733 at cingularme.com
WEB:    http://gcn.gsfc.nasa.gov/gcn


FOOTNOTES:
[1]  The GCN/TAN VOEvents will continue to be distributed through Skyalert
(see http://www.skyalert.org/).  The NOAO and Exeter servers are no longer on-line.

[2]  This transition of the name change (from GCN to TAN) will not affect
any format or content of the current set of GCN Notices and VOEvents.
So if you are using code/scripts which search for specific strings
(say in email-based formats), there will be NO change.  Your code
will continue to work as is.  (Only newly created Notice types will have content
reflecting the new name.)  GCN/TAN will always be backward compatible for the customers.

[3]  There is only one exception to that firewall ban on all incoming connections: HEASARC.
HEASARC is also a true server with non-prearranged incoming connections.  HEASARC has been
grandfathered in for the "anonymous" open firewall hole.  GCN/TAN will not be given
a similar hole.

[4]  Actually, "anonymously" means without any prior arrangements,
no configuration set-ups, nor any entry to some "allowed to connect" list.
In practice, the GCN/TAN server will always be able to obtain your IP Number
when you connect (with or without a prior configuration set-up).

[5]  Connecting anonymously means you do not -- can not -- have a VOEvent-based entry
in the sites.cfg file.  Every new connection has its IP_Num checked against
those in the sites.cfg file.  If there is a match, then the connection immediately
converts from anonymous to vetted (your identity and configuration are known and used).

[6]  And the ~12 other "team internal" notice types for the Fermi and Swift 
Operations Teams are also available in this vTCP VOEvent protocol/format.


(You can take this opportunity to review your current configuration
and request changes (see http://gcn.gsfc.nasa.gov/gcn/config_builder.html
Selection #2) or your can just tell me what you want changed, but please
include your config below so (a) I know your site_name, and (b) you mark the
differences/changes.)
//////////////////////////////// Your Current Configuration /////////////////////////

BEGIN_SITE
SITE_NAME  VSNET
DATES      25jun05   23oct07
SITE_LON_LAT   135.75   35.00
DIST_METHOD   EMAIL
DIST_ADDRESS  vsnet-grb at ooruri.kusastro.kyoto-u.ac.jp
POC_NAME      Daisaku Nogami
POC_ADDRESS   vsnet-grb at ooruri.kusastro.kyoto-u.ac.jp
DAILY_REPORT_ENABLE   0
DAILY_REPORT_ADDRESS  vsnet-grb at ooruri.kusastro.kyoto-u.ac.jp
# Site-specific items:
TRIGGER_ID     0
INTENSITY      -1.0
ERROR          360.1000
DELAY          999.9
SIGNIFICANCE   0.00
CONF_LEVEL     0.00
OBSERVABILITY  ALL
ATTACHMENT     NONE
SIMBAD_NED     0
# Type-specific items:
IPN_POS
INTEGRAL_SPIACS
INTEGRAL_WAKEUP
INTEGRAL_REFINED
INTEGRAL_OFFLINE
KONUS_LC
SWIFT_BAT_GRB_ALERT
SWIFT_BAT_GRB_POS  trig_id=0
SWIFT_BAT_GRB_NACK_POS
SWIFT_BAT_GRB_LC  trig_id=0
SWIFT_FOM_2OBS  trig_id=0
SWIFT_SC_2SLEW  trig_id=0
SWIFT_XRT_POS
SWIFT_XRT_NACK_POS
SWIFT_XRT_IMAGE
SWIFT_XRT_PROC_IMAGE
SWIFT_UVOT_POS  inten=99.00
SWIFT_UVOT_IMAGE
SWIFT_UVOT_PROC_IMAGE
SWIFT_UVOT_SRCLIST
SWIFT_UVOT_PROC_SRCLIST
SWIFT_POINTDIR
SWIFT_TOO_FOM
SWIFT_TOO_SLEW
END_SITE