[LDM #CSZ-262645]: errant LDM REQUESTs on sirocco.srcc.lsu.edu

Hi Jeffry and David,

Jeffry said:
> I saw their response. There can be many factors doing this. Until we get
> a good sniff, it will be hard to pinpoint.

We agree.

re:
> Hopefully tomorrow they will
> open it up and we should be able to capture something.

Things are open now.

You can run tests as you see fit by uncommenting the REQUEST
line to uni20.unidata.ucar.edu in ~ldm/etc/ldmd.conf and then
restarting the LDM on sirocco.

NB: We ask that you do not leave the REQUEST to uni20.unidata.ucar.edu
active for extended periods of time. The reason for our request is
that the number of upstream feed processes activated to send data
to sirocco will grow until an effective denial of service is experienced.
When we see a situation like this, we will be forced to act by blacklisting
sirocco's IP address in the firewall on uni20.

re:
> Meanwhile, would you draw up and explain how connections are supposed to
> happen between you and them and you and your clients.

All LDM to LDM feeds are initiated by the downstream (e.g., sirocco).
The LDM administrator on the downstream machine adds/uncomments one
or more REQUESTs to an upstream and than restarts his/her LDM.  The
downstream LDM sends a request to the top level LDM process on the
upstream and it spawns off a process to service the REQUEST after
verifying that the ldmd.conf on the upstream is configured to ALLOW
the feed REQUEST.  The sense of the connection is turned around at
this point: the upstream sends data to the downstream as products
specified in the downstream's REQUEST become available in its LDM
queue.  The connection is persistent -- it will stay active for as
long as the downstream process still exists and the upstream LDM
stays running.

The situation we are seeing is that ** something ** is inserting
a reset packet into the stream being sent to the downstream.  The
downstream LDM gets the reset and assumes that it originated at
the upstream.  The downstream process exits upon receipt of the
reset, and the top level LDM process on the downstream notices
that the instance that was feeding has exited, so it starts a
new one

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: CSZ-262645
Department: Support LDM
Priority: Normal
Status: Open