Maintaining socket connections

[James Wiggs <wiggs wiggs org>]

 Folks,

   I posted this on the gtk list and got no responses, so I'll
try posting here.  I'm not so much asking for specific debugging
suggestions as asking a more general question about the stability
of glib and gnet as a platform for developing TCP applications
that must have a very high degree of robustness and be able to
handle moving fairly large volumes of data on a daily basis.  The
application in question moves about 1.5-2.0 GB of data per day,
most of it from 9:30 AM and 4:00 PM EST (when the North American
equities markets are open).

   I'm working on a pair of processes, one multithreaded and one
single-threaded.  The multithreaded process monitors incoming data
on a TCP socket and a UDP socket, captures the data as it comes in
and cleans it up, then writes it through another TCP socket to the
second process.  I am running into problems with that socket just
closing off intermittently.  Both processes are still running, but
the data stops flowing.  No errog log output to indicate that the
socket is broken, nothing.  It just stops working.  The receiving
process tries to read the socket and gets nothing, and the sending
process stops writing packets because the socket is no longer
writable.  I've got code in place that is supposed to close the
socket and reconnect (on G_IO_ERR, _HUP and _NVAL), but it doesn't
seem that it ever gets triggered.

   On the receiving end, I'm just using vanilla socket code; on
the multithreaded side, I'm using gnet and giochannels.  This
code originally connected through a UNIX socket but I'm trying
to make it network-capable.  The UNIX socket version would stay
up for literally *MONTHS* at a time.  I MUST have that level of
stability.  Am I wasting my time?  Is glib and giochannels not
capable of providing that?  Can anyone point me to an app that
successfully uses them to maintain a *constant* connection, with
automatic reconnection if the connection is somehow lost?  I
just want to know that it *can* be done...

thanks,
Jim