ECONNRESET on server

Post by Les Cargill
Is the following statement correct, incorrect or in need of amendment?
(You'd think you could Google for it, and you would be wrong ).
If a TCP/IP server has a select()/recv() loop, and an error of
ECONRESET is ever encountered, the server *must* close the connection?
(paraphrasing)
Are there transient ECONNRESET ... states in TCP/IP?

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?

As far as I know, ECONNRESET says the connection is irrevocably lost,
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.

/Jorgen

PS. You write "TCP/IP", but you mean TCP, right?

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Les Cargill

2013-09-30 12:32:26 UTC

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?

It *can't* be that easy. :)

Post by Jorgen Grahn
As far as I know, ECONNRESET says the connection is irrevocably lost,

That's what I would think, yes.

Post by Jorgen Grahn
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.

Bingo. Neither does the developer of it... looks like
there's UDP on my future. Just not today.

Post by Jorgen Grahn
/Jorgen
PS. You write "TCP/IP", but you mean TCP, right?

Yes. The "/IP" just kind of typed itself, and I'm never quite sure if
the same applies to layer 3 other than IPv4 over Ethernet.

--
Les Cargill

Jorgen Grahn

2013-09-30 15:16:35 UTC

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?

It *can't* be that easy. :)

Post by Jorgen Grahn
As far as I know, ECONNRESET says the connection is irrevocably lost,

That's what I would think, yes.

Post by Jorgen Grahn
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.

Bingo. Neither does the developer of it... looks like
there's UDP on my future. Just not today.

UDP doesn't solve that problem, if that's what you mean. It's one of
those classic problems ... does it have a name? IRTR an allegory with
one general sending someone with a message to the battlefield, and not
being sure the message or the reply got lost.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Barry Margolin

2013-09-30 15:21:59 UTC

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?

It *can't* be that easy. :)

Post by Jorgen Grahn
As far as I know, ECONNRESET says the connection is irrevocably lost,

That's what I would think, yes.

Post by Jorgen Grahn
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.

Bingo. Neither does the developer of it... looks like
there's UDP on my future. Just not today.

It's the "two generals problem".

http://en.wikipedia.org/wiki/Two_Generals'_Problem

In TCP it's an issue with orderly closes. Connection resets are even
worse, since they're asynchronous.

--
Barry Margolin
Arlington, MA

Les Cargill

2013-09-30 17:41:16 UTC

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?

It *can't* be that easy. :)

Post by Jorgen Grahn
As far as I know, ECONNRESET says the connection is irrevocably lost,

That's what I would think, yes.

Post by Jorgen Grahn
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.

Bingo. Neither does the developer of it... looks like
there's UDP on my future. Just not today.

UDP doesn't solve that problem, if that's what you mean.

I respectfully disagree. It enables the actual solution to
this problem by moving the retransmission logic into app space.

Post by Jorgen Grahn
It's one of
those classic problems ... does it have a name? IRTR an allegory with
one general sending someone with a message to the battlefield, and not
being sure the message or the reply got lost.

http://en.wikipedia.org/wiki/Two_Generals%27_Problem

Post by Jorgen Grahn
/Jorgen

--
Les Cargill

Jorgen Grahn

2013-09-30 19:24:41 UTC

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?

It *can't* be that easy. :)

Post by Jorgen Grahn
As far as I know, ECONNRESET says the connection is irrevocably lost,

That's what I would think, yes.

Post by Jorgen Grahn
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.

Bingo. Neither does the developer of it... looks like
there's UDP on my future. Just not today.

UDP doesn't solve that problem, if that's what you mean.

I respectfully disagree. It enables the actual solution to
this problem by moving the retransmission logic into app space.

What can you do with UDP which you cannot to with TCP? You can always
reconnect and try to fix the situation, if the application protocol
provides a way.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

glen herrmannsfeldt

2013-09-30 19:34:01 UTC

Jorgen Grahn <grahn+***@snipabacken.se> wrote:

(snip)

Post by Les Cargill
I respectfully disagree. It enables the actual solution to
this problem by moving the retransmission logic into app space.

What can you do with UDP which you cannot to with TCP?

Multicast.

Post by Jorgen Grahn
You can always reconnect and try to fix the situation, if
the application protocol provides a way.

The point is, that with UDP the user program itself is responsible
for keeping track of retransmits and acks, as needed.

The other difference is that UDP maintains packet boundaries,
where TCP does not. With the change from NFS/UDP to NFS/TCP,
(and to RPC in general) there is the record marking standard to
allow including record boundaries in a TCP stream.

-- glen

Jorgen Grahn

2013-09-30 20:27:38 UTC

Post by glen herrmannsfeldt
(snip)

Post by Les Cargill
I respectfully disagree. It enables the actual solution to
this problem by moving the retransmission logic into app space.

What can you do with UDP which you cannot to with TCP?

Multicast.

Post by Jorgen Grahn
You can always reconnect and try to fix the situation, if
the application protocol provides a way.

OK, so these are things you like about UDP in general -- but we seem
to agree that UDP doesn't solve "Two Generals".

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Les Cargill

2013-10-01 03:01:57 UTC

Post by glen herrmannsfeldt
(snip)

Post by Les Cargill
I respectfully disagree. It enables the actual solution to
this problem by moving the retransmission logic into app space.

What can you do with UDP which you cannot to with TCP?

Multicast.

Post by Jorgen Grahn
You can always reconnect and try to fix the situation, if
the application protocol provides a way.

OK, so these are things you like about UDP in general -- but we seem
to agree that UDP doesn't solve "Two Generals".
/Jorgen

It does not. I beleive theres a proof that there is no
solution to the Two Generals problem - outside of
the places they keep infinte bandwidth channels and
perpetual motion machines :)

--
Les Cargill

Les Cargill

2013-10-01 03:00:32 UTC

Post by glen herrmannsfeldt
(snip)

Post by Les Cargill
I respectfully disagree. It enables the actual solution to
this problem by moving the retransmission logic into app space.

What can you do with UDP which you cannot to with TCP?

Multicast.

Post by Jorgen Grahn
You can always reconnect and try to fix the situation, if
the application protocol provides a way.

The point is, that with UDP the user program itself is responsible
for keeping track of retransmits and acks, as needed.

Right. You know where you stand at all times.

Post by glen herrmannsfeldt
The other difference is that UDP maintains packet boundaries,
where TCP does not. With the change from NFS/UDP to NFS/TCP,
(and to RPC in general) there is the record marking standard to
allow including record boundaries in a TCP stream.
-- glen

--
Les Cargill

glen herrmannsfeldt

2013-09-30 19:13:19 UTC

Jorgen Grahn <grahn+***@snipabacken.se> wrote:

(snip, someone wrote)

Post by Les Cargill
(paraphrasing)
Are there transient ECONNRESET ... states in TCP/IP?

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?
As far as I know, ECONNRESET says the connection is irrevocably lost,
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.
PS. You write "TCP/IP", but you mean TCP, right?

(snip)

As opposed to TCP carried by some other lower level protocol?
Maybe TCP/DDP?

In the MacOS 7 and 8 days, I used to wonder about why no ATP/IP.
It would have made it much easier to use Macs on IP networks.

-- glen

Jorgen Grahn

2013-09-30 19:32:36 UTC

Post by glen herrmannsfeldt
(snip, someone wrote)

Post by Les Cargill
(paraphrasing)
Are there transient ECONNRESET ... states in TCP/IP?

That would make ECONNRESET both meaningless and mislabeled,
wouldn't it?
As far as I know, ECONNRESET says the connection is irrevocably lost,
and there's nothing you can do about it. And you also don't know
exactly what the peer application's state was before the problem.
PS. You write "TCP/IP", but you mean TCP, right?

(snip)
As opposed to TCP carried by some other lower level protocol?
Maybe TCP/DDP?

"TCP/IP" usually stands for "IP and the various protocols on top of
it" rather than TCP in particular -- see e.g. the name of this
newsgroup!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

glen herrmannsfeldt

2013-09-30 20:45:30 UTC

Jorgen Grahn <grahn+***@snipabacken.se> wrote:

(snip, I wrote)

Post by glen herrmannsfeldt
(snip)
As opposed to TCP carried by some other lower level protocol?
Maybe TCP/DDP?

"TCP/IP" usually stands for "IP and the various protocols on top of
it" rather than TCP in particular -- see e.g. the name of this
newsgroup!

Yes, and I always note when someone mentions TCP/IP in the context
of UDP. The assumption is that you always have to implement TCP,
but that isn't true.

If it has to fit in a small ROM (such as diskless booting) or in
hardware (FPGA) then UDP is much easier.

There could be TCP over other layer 3 (network) protocols, though
I don't know of any. But I do like mentioning protocols, including
the lower level, such as NFS/UDP and NFS/TCP with a slash separator.
I suppose it could be NFS/UDP/IP. In some cases, one might need to
distinguish the layer 2 protocol, TCP/IP/etherent or TCP/IP/tokenring.

-- glen

Barry Margolin

2013-10-01 00:36:09 UTC

Post by glen herrmannsfeldt
(snip, I wrote)

Post by glen herrmannsfeldt
(snip)
As opposed to TCP carried by some other lower level protocol?
Maybe TCP/DDP?

"TCP/IP" usually stands for "IP and the various protocols on top of
it" rather than TCP in particular -- see e.g. the name of this
newsgroup!

Technically true. Although only really practical if you only make fairly
limited use of the network, e.g. just for diskless booting or
configuration with DHCP. If you do anything more complex, like
providing a web-based UI or terminal interface for configuring the
device, you'll need TCP.

So the boot ROM might only need UDP, but whatever it loads in will
almost certainly include TCP.

--
Barry Margolin
Arlington, MA

glen herrmannsfeldt

2013-10-01 01:24:47 UTC

Barry Margolin <***@alum.mit.edu> wrote:

(snip, I wrote)

Post by Barry Margolin

Post by glen herrmannsfeldt
Yes, and I always note when someone mentions TCP/IP in the context
of UDP. The assumption is that you always have to implement TCP,
but that isn't true.
If it has to fit in a small ROM (such as diskless booting) or in
hardware (FPGA) then UDP is much easier.

Technically true. Although only really practical if you only make fairly
limited use of the network, e.g. just for diskless booting or
configuration with DHCP. If you do anything more complex, like
providing a web-based UI or terminal interface for configuring the
device, you'll need TCP.
So the boot ROM might only need UDP, but whatever it loads in will
almost certainly include TCP.

Some years ago, I was installing and configuring diskless Suns,
and got pretty used to how they worked. That included using
etherfind to debug problems with hex dumps of the packets.
Mostly from memory:

First a Sun machine uses RARP to find its own address.

Then UDP based TFTP to download the first level boot program,
presumably using a broadcast address as it doesn't know the
server address. Actually, I think they changed somewhere along
the line to use the address of the server replying to the RARP
request.

Then RPC based BOOTPARAMD to find the name and IP address
of the server, and some other such data.

I believe after that, most is done through NFS, which was UDP
based in those days. I am less sure now, but I believe it loads
the second level boot program and runs that, which again uses
RARP and BOOTPARAMD to determine the server and root file system,
which it then NFS mounts and loads.

At that point, it is executing the kernel from the root file system,
which includes most everything else it needs to know, including
other partitions to mount.

I didn't do any diskless Sun work since the change to NFS/TCP,
but it seems likely that is what more recent systems would do.

-- glen

glen herrmannsfeldt

2013-10-01 02:11:57 UTC