HP3000-L Archives

July 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tracy Johnson <[log in to unmask]>
Reply To:
Date:
Tue, 10 Jul 2001 19:34:41 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)
Bruce Toback wrote:
>
> Tracy Johnson writes:
>
> >Sometime afterwards, the HP calls with another
> >solution to the dilemma.  A Beta Patch that changes
> >the way UDP behaves.
> >
> >Seems UDP is single-threaded on the HPe3000.
>
> Hmm... this doesn't make any sense. UDP is a connectionless protocol,
> meaning that unlike TCP, the lower levels of the networking stack don't
> know or care about responses to UDP packets. So there's nothing to
> "thread" at the network level.

I don't know if it makes any "sense", but that is exactly what the HP
rep told me, that it was "single-threaded".  If you still disagree,
contact HP to find out the truth.

> >The
> >Spoolers are SNMP, which by some process that I
> >can only call magic, works under UDP.
>
> Network communications use a hierarchy of protocols, each of which
> specifies some part of the addressing and routing for the message. A
> process that wants to query a node via SNMP creates a UDP packet with the
> SNMP message in it, then sends the packet out. Incidentally, the spoolers
> use SNMP only for printer status, not for printing.

O.K. but it is still "magic" to me!

> >The beta patch that HP is providing, will either
> >do one of two things:
> >
> >1)  UDP will become multi-threaded, like TCP and
> >start spawning separate processes or,
> >
> >2)  UDP will become tweaked so that the time-out
> >for it will not be so long.
>
> This has to refer to the spooler process specifically, not to UDP in
> general.
>
> >(Note there is nothing in NMMGR that affects how
> >long UDP waits for a time out.  So there is nothing
> >that can be self-corrected there.)
>
> Again, that's because there's no such thing as a timeout for a UDP
> packet. Each packet is complete in and of itself, so once the packet is
> sent, there's no reply to wait for. (The process that sent it might be
> waiting for a reply, but that's not the business of the network code.)

Maybe he was referring to UDP as a process waiting for a semaphore
from a lower level process, and not network traffic.

> >It is assumed something on the network has changed
> >for this gateway, but it is not yet determined
> >what it is.  The circuit and router is maintained
> >by a vendor who denies any changes.
>
> Are they suddenly blocking SNMP? That wouldn't surprise me; SNMP
> generally has no business going across the Internet except to networks
> known in advance.

They're not getting sent out into the great internet cloud, but
rather to other routers on a private frame relay.  However the
router and circuit is being maintained by 2nd party that has a
temporary business relationship that is about to close (per a
schedule).  We have no clue if they may have changed something
(globally or locally) without notification.

> -- Bruce
>
--
BT
NNNN
Tracy Johnson

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2