experchange > programmer

Rainer Weikusat (10-23-18, 11:29 PM)
Just noted while testing a TCP client by connecting to a socket on the
same computer: Assuming a connection was established and a message sent and
the listening program is then terminated, a second send over the socket
will succeed and the 3rd will be terminated by SIGPIPE/ EPIPE.

Example (Perl):

-------
use Socket;

if (fork() == 0) {
my $sk;
socket($sk, AF_INET, SOCK_STREAM, 0) or die("socket: $!");

my $ip = inet_aton('127.0.0.1');
bind($sk, pack_sockaddr_in(20203, $ip)) or die("bind: $!");

listen($sk, 10) or die("listen: $!");

my$conn;
accept($conn, $sk) or die("accept: $!");

my $in;
sysread($conn, $in, 4) or die("sysread: $!");
exit(0);
}

sleep(1);
$SIG{PIPE} = 'IGN';

my $sk;
socket($sk, AF_INET, SOCK_STREAM, 0) or die("socket: $!");

my $ip = inet_aton('127.0.0.1');
connect($sk, pack_sockaddr_in(20203, $ip)) or die("connect: $!");

syswrite($sk, "1234") or die("syswrite: $!");
print STDERR ("w0\n");
sleep(5);

syswrite($sk, "1234") or die("syswrite: $!");
print STDERR ("w1\n");
sleep(1);

syswrite($sk, "1234") or die("syswrite: $!");
print STDERR ("w2\n");
-------

As tested on Linux 3.16.48 and 4.5.0, this will print

w0
w1
syswrite: Broken pipe at a.pl line 37.

and the successful w1 write can be seen in strace output.
Casper H.S. Dik (10-24-18, 01:19 PM)
Rainer Weikusat <rweikusat> writes:

>Just noted while testing a TCP client by connecting to a socket on the
>same computer: Assuming a connection was established and a message sent and
>the listening program is then terminated, a second send over the socket
>will succeed and the 3rd will be terminated by SIGPIPE/ EPIPE.


This is pretty much normal TCP/IP behaviour.

The second write will succeed and only after the remote host returns
an error, Then the 3rd write will detect the error and the kernel
will notify the process.

Casper
Rainer Weikusat (10-24-18, 03:58 PM)
Casper H.S. Dik <Casper.Dik> writes:
> Rainer Weikusat <rweikusat> writes:
> This is pretty much normal TCP/IP behaviour.
> The second write will succeed and only after the remote host returns
> an error, Then the 3rd write will detect the error and the kernel
> will notify the process.


There is no "remote host" involved here. When using a remote host for
testing, the 2nd write aborts with ECONNRESET. This is happening with
loopback connections on one host, as the example program should have
shown.
Barry Margolin (10-24-18, 04:27 PM)
In article <87k1m7phte.fsf>,
Rainer Weikusat <rweikusat> wrote:

> Casper H.S. Dik <Casper.Dik> writes:
> There is no "remote host" involved here. When using a remote host for
> testing, the 2nd write aborts with ECONNRESET. This is happening with
> loopback connections on one host, as the example program should have
> shown.


The modularity of the TCP stack makes it act the same for loopback
connections as real network connections. When you call send(), it just
buffers the data and returns immediately.
Rainer Weikusat (10-24-18, 04:49 PM)
Barry Margolin <barmar> writes:
> Rainer Weikusat <rweikusat> wrote:
> The modularity of the TCP stack makes it act the same for loopback
> connections as real network connections. When you call send(), it just
> buffers the data and returns immediately.


Considering that the pseudo-remote socket has ceased to exist and that
the kernel knows this, this is at least very silly behaviour as it
causes avoidable, silent loss of data.

One can obviously argue that there is no such thing as a reliable,
transport-layer protocol or at least that "everybody knows" that TCP
isn't one but unless I'm very much mistaken, that's far from being
something "everybody knows".
Casper H.S. Dik (10-24-18, 06:34 PM)
Rainer Weikusat <rweikusat> writes:

>Casper H.S. Dik <Casper.Dik> writes:


>There is no "remote host" involved here. When using a remote host for
>testing, the 2nd write aborts with ECONNRESET. This is happening with
>loopback connections on one host, as the example program should have
>shown.


That doesn't change how TCP/IP works.

Casper
Casper H.S. Dik (10-24-18, 06:35 PM)
Rainer Weikusat <rweikusat> writes:

>Barry Margolin <barmar> writes:


>Considering that the pseudo-remote socket has ceased to exist and that
>the kernel knows this, this is at least very silly behaviour as it
>causes avoidable, silent loss of data.
>
>One can obviously argue that there is no such thing as a reliable,
>transport-layer protocol or at least that "everybody knows" that TCP
>isn't one but unless I'm very much mistaken, that's far from being
>something "everybody knows".


How useful is it to have a form of communication which you cannot
test if you run the server and the client on the same host because
it works differently when there are two different hosts?

Casper
Rainer Weikusat (10-25-18, 04:28 PM)
Casper H.S. Dik <Casper.Dik> writes:
> Rainer Weikusat <rweikusat> writes:
> How useful is it to have a form of communication which you cannot
> test if you run the server and the client on the same host because
> it works differently when there are two different hosts?


It's the same kind of sillyness in both cases: The TCP implementation on
the remote endpoint perfectly well knows that future sends won't
succeed. Instead of initiating a cooperative, half-duplex shutdown, it
should notify the other pary of this fact and preferably, provide
information about which data was actually received. This could easily be
done within the existing communication framework.

TCP basically has the assumption that application software never fails
unless the computer it's running on suddenly explodes or some other
"total system failure" event occurs baked into it.
Nicolas George (10-25-18, 05:35 PM)
Rainer Weikusat , dans le message
<87va5qgkwo.fsf>, a écrit :
> It's the same kind of sillyness in both cases:


Since you are obviously so much more competent than Jon Postel and his
team, please show us your projects to redesign the Internet protocols
entirely.
Kaz Kylheku (10-25-18, 07:03 PM)
On 2018-10-25, Nicolas George <nicolas$george> wrote:
> Rainer Weikusat , dans le message
><87va5qgkwo.fsf>, a écrit :
>> It's the same kind of sillyness in both cases:

> Since you are obviously so much more competent than Jon Postel and his
> team, please show us your projects to redesign the Internet protocols
> entirely.


On this topic:

I'd take IPv4 and just widen addresses to 64 bits (with textual notation
x.y.z.w where these are 0 to 65535). Port numbers would be 32.
Everything else would be the same as IPv4 otherwise. ARP would be
widened to these addresses, and so on.

IPv4 would be embedded in IPv5 such that an IPv4 address like 1.2.3.4
would stay the same, only these numbers are re-interpreted as 16 bits
wide.

Communication between an IPv5 and IPv4 endpoint would be possible
through a protocol-converting NAT. An IPv5 client endpoint would be able
to reach IPv4 servers; the outbound IP datagrams would be captured by
the protocol-converting NAT, and narrowed to IPv4 format; in the reverse
direction, IPv4 datagrams coming from the server would be widened to
IPv5. This would allow expansion of the space to accomodate more
clients, without requiring all servers to migrate to new protocol.
Rainer Weikusat (10-25-18, 07:30 PM)
Nicolas George <nicolas$george> writes:
> <87va5qgkwo.fsf>, a écrit :
>> It's the same kind of sillyness in both cases:

> Since you are obviously so much more competent than Jon Postel and his
> team, please show us your projects to redesign the Internet protocols
> entirely.


Since you certainly have some kind of argument against what I was
proposing (which is - BTW - based on a real-world application issue I'll
have to deal with), why don't you just bring that forth instead accusing
me of "obviously not being Jon Postel!".

Hint: TCP has been worked on a lot since 1981. Mostly people whose names
were neither Jon nor Postel.

No, I don't expect a cogent reply to this.
Grant Taylor (10-25-18, 07:49 PM)
On 10/25/2018 11:03 AM, Kaz Kylheku wrote:
> I'd take IPv4 and just widen addresses to 64 bits (with textual notation
> x.y.z.w where these are 0 to 65535). Port numbers would be 32. Everything
> else would be the same as IPv4 otherwise.


Okay.

> ARP would be widened to these addresses, and so on.


Nothing about the ARP protocol needs to be modified to support this.

ARP can handle different sized (length) protocol (and hardware)
addresses already in it's current form.

> IPv4 would be embedded in IPv5 such that an IPv4 address like 1.2.3.4
> would stay the same, only these numbers are re-interpreted as 16 bits
> wide.


~wince~

I get the spirit of what you're saying. But I think there would be some
complications.

> Communication between an IPv5 and IPv4 endpoint would be possible through
> a protocol-converting NAT. An IPv5 client endpoint would be able to
> reach IPv4 servers; the outbound IP datagrams would be captured by the
> protocol-converting NAT, and narrowed to IPv4 format; in the reverse
> direction, IPv4 datagrams coming from the server would be widened to
> IPv5. This would allow expansion of the space to accomodate more clients,
> without requiring all servers to migrate to new protocol.


I suspect that you're talking about making the IPv4 address space be a
subset of (what you're calling) the IPv5 address space.

You will have some complications, particularly with traffic originating
from IPv5 that is not in the IPv4 address space. Likewise with ports.

Crude ASCII Venn diagram:

+---------------+
| IPv5 |
| |
| |
| +------+ |
| | IPv4 | |
| +------+ |
+---------------+

There are some hacks that you can do (like defining that IPv5 doesn't
include the leading 8 zero bits) but you end up with a complicated protocol.

I think it's better to view IPv4 and IPv<anything other than 4> as
completely independent protocols. You might as well gateway between
IPv4 and IPX.
Nicolas George (10-25-18, 09:09 PM)
Rainer Weikusat , dans le message
<87r2gegchh.fsf>, a écrit :
> Since you certainly have some kind of argument against what I was
> proposing (which is - BTW - based on a real-world application issue I'll
> have to deal with), why don't you just bring that forth instead accusing
> me of "obviously not being Jon Postel!".


Because my message was not technical, it was about using sarcasm to
underline the hubris of somebody who has repeatedly proven his inability
to read docs and write clean code and dares calling well-established
protocols "silly".

But it was not directed at you, it was directed at the others readers on
this group. When somebody is so far gone into ridicule, I do not know
how to reach him.

Please, have the last word.
Rainer Weikusat (10-25-18, 11:39 PM)
Rainer Weikusat <rweikusat> writes:

[...]

> The TCP implementation on the remote endpoint perfectly well knows that
> future sends won't succeed. Instead of initiating a cooperative,
> half-duplex shutdown, it should notify the other pary of this fact and
> preferably, provide information about which data was actually
> received.


An obvious counterargument: The only guarantee that an application has
actually processed some data is some sort of application-level ack. A
TCP implementation in the kernel has no way to know if this is true for
some data it passed to an application.
Similar Threads