Subject: Code updates
From: corrinne mills (cmills@budoe.bu.edu)
Date: Mon Sep 11 2000 - 10:44:08 EDT
Hello all,
i'm corrinne mills, an undergrad at Harvard University. i've spent this
summer working at Boston University with Kate Scholberg and Alec Habig on
the SNNEWS supernova coincidence code.
This email is an overview of the changes/additions i made to the
coincidence code this summer.
The quick version (an overview of the overview, if you will):
o alarm retraction
- specify time range and experiment to retract
- both C- and Fortran-callable routines exist
- a command line interface, retract_util, also exists
o OpenSSL: secure sockets implementation
- the code is now connection-based (TCP) instead of UDP.
- connections are encrypted
- client and server authenticate each other with digital
certificates.
o multiple-platform builds
- gc_config uses configure to build a Makefile from Makefile.in
- configure can be regenerated using autoconf.
- Makefile.in is based on the older Makefiles.
----------------------------------------------------------
alarm retraction
The gcretcli routine, the retraction client, is very similar to the two
previous clients, gcpingcli and gccli. It takes two datetime arguments,
in the same format as the datetime arguments for the other client routines,
and one integer argument, which specifies the experiment. The two datetime
arguments specify the time range to retract. When the gcserver receives the
retraction request packet, it removes all alarms from the named experiment that
fall between the datetime arguments (inclusive) from the alarm queue. To
remove one specific packet, its exact datetime (down to the nanosecond
field) should be given as both datetimes.
A command-line program, retract_util, is also included in the coincidence
code module, and provides a simple interface (but easier to use than the
two test programs) to the retraction routine. I made it since i figured
that it would usually be a human and not a computer retracting alarms.
In the future it might be nice to be able to specify a sequence number
range to retract, if the sequence numbers are paid more attention to.
----------------------------------------------------------
OpenSSL: secure sockets implementation.
Since OpenSSL can only run on connection-based (TCP) network protocol, the
coincidence code has been switched to using TCP connections. This has the
nice side effect of gaining TCP's reliablity: the protocol guarantees
arrival and sequencing.
The connections are now encrypted, using public-key cryptography
(see http://www.pgpi.org/doc/pgpintro/ for an overview of how this works:
we aren't using pgp, but the math is the same.) This means that if someone
intercepts our packets, they can't read them.
Part of the TPC protocol (and an integral part of the secure sockets layer)
is the initial "handshake" between client and server. In the handshake,
they exchange information about the new connection. For SSL, they negotiate
a shared cipher (i.e., encryption algorithm) and exchange digital certificates.
A digital certificate for a given entity consists of their private key
(usually password encrypted, i'll get to that in a minute), and of the
public key of any certifying authority (CA) who has "signed" their certificate.
i have set up a "certifying authority" called gcCA on superk.bu.edu, one of
the computers at B.U. Certificates should be emailed to me to be signed.
All certificates for the coincidence clients and servers need to be signed
by gcCA, since one of the checks that both the client and the server do
is to compare a hash of the public key of the CA who signed their peer's
(the other computer in the connection) certificate. If these are not exactly
the same, the connection will be refused. This authentication, which happens
on both the client and the server side, is one of the major upgrades to
the code. For more information on how to deal with certificates, see
the README file that is now included in the code module, or look at
the working group's web pages, under code documentation and job lists.
------------------------------------------------------
Mulitple platform builds
configure is a script that automatically generates a Makefile from a
Makefile.in, converting variables in Makefile.in into system-dependent
library paths, header file paths, and compiling and linking flags
(among many other things, but those are what we're using it for).
configure itself is automatically generated from configure.in
by the gnu tool autoconf. configure, however, requires a configure.in
to tell autoconf what kinds of things to have the configure script look for.
A person needs to write configure.in, but they have a few resources.
Autoscan looks at the code, and from that generates configure.scan, which
indicates libraries and structures that configure should look for.
Other things will need to be added, though, before configure.scan can
be renamed to configure.in. The autoconf manual page at gnu.org
(http://www.gnu.org/manual/autoconf) has a lot of helpful information for
that. The error messages generated by autoconf when you try to generate
configure from configure.in, but don't have everything you need, are
also useful.
I've tested our particular setup on Linux and Solaris. The generality of the
configure script should imply that it will work on other systems, too.
How have the files changed in the coinccode module? a lot. Makefile.linux
and Makefile.solaris_sparc are gone. Files that are included with the
module are: Makefile.in, gc_config, configure, and configure.in. configure.in
is included so that developers can remake configure, and also because
it is much more readable than configure itself, and explains much of what
configure does.
------------------------------------------------------
for more information, check
- the working group webpages, especially code documentation and to do lists.
(http://hep.bu.edu/~snnet/wg/coinccode/code_docs.html)
(http://hep.bu.edu/~snnet/wg/joblist.html)
(http://hep.bu.edu/~snnet/wg/coinccode/todo.html)
- the README in the current coinccode module (this is particularly verbose).
it has a lot of installation and troubleshooting info.
(http://hep.bu.edu/~snnet/wg/coinccode/readme.html)
- comments in the code itself.
or, feel free to email me at cmills@superk.bu.edu
corrinne mills
This archive was generated by hypermail 2a24 : Mon Sep 11 2000 - 10:44:52 EDT