Standards Update, IEEE 1003.4: Real-time Extensions

[Dan Bernstein]

Submitted-by: brnstnd at kramden.acf.nyu.edu (Dan Bernstein)

In article <546 at usenix.ORG> henry at zoo.toronto.edu (Henry Spencer) writes:
> I'm afraid I don't understand:  a program that is trying, simultaneously,
> to open several different connections is somehow not doing several things
> at once?

Correct. Between sending an open request out upon the network and
receiving an acknowledgment, the program is not doing anything at all
related to that connection.

Let me be more specific. Host X, on the Internet, wants to know the
time. It decides to ask ten hosts around the network for the time.

In reality, here's what happens in X's interaction with Y: X sends to Y
a request for a connection on port 37. Pause. Y acknowledges. Y sends a
few bytes back and closes the connection. During the pause, X is doing
nothing.

But there are several Y's. So X sends out ten requests in sequence. It
waits. Each Y responds at some point; X collects the responses in
whatever order they come. Where is it doing any two things at once, let
alone several?

> The program *is* doing several things at once, to wit opening several
> connections at once.

``Opening a connection'' is really an abuse of the language, because a
network open consists of at least two steps that may come arbitrarily
far apart. Let me replace it by phrases that honestly describe what the
computer is doing: ``sending out a connection request, and later
accepting an acknowledgment.''

Now, out of the requests and acknowledgments going on, what two are
happening at once? None of them. You're being misled by the terminology.
``Opening a connection'' is such a common phrase that we automatically
accept it as a description of reality, and consequently believe that it
is well described by open(); but it isn't. The time between request and
acknowledgment is filled with nothing but a void.

  [ combining threads with a one-step open() ]
> This is a far more natural model of what's
> going on than forcing everything into one sequential process, and a
> much better match for the semantics of the problem.

No. It is not an accurate description of what is going on, since an
open() is implicitly local while a network open is not.

Abstract imagery aside, though, ``naturalness'' is really defined by how
a concept helps a programmer. BSD's non-blocking connect() and select()
for connection acceptance, while perhaps not the best-named system
calls, are extremely easy to work with. They adapt perfectly to network
programming problems because they accurately reflect what the system is
doing. In contrast, forking off threads and kludging around a local
open() is unnecessarily complex and would make network programming
unnecessarily difficult. For me that condemns it as an unnatural,
inaccurate reflection of reality.

---Dan

Volume-Number: Volume 21, Number 135