-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
John,
On 3/31/20 10:37, John Dale wrote:
> I always appreciate your depth of knowledge, Chris.
>
> "hand-wavy device supporting NIO for Java"
>
> Could you write us a quick paragraph expanding on this idea?
>
> I'm happy to follow a pointer to a well written article (something
> up to your standards).
I mostly called it "hand-wavy" because I do not understand it myself:
it's indistinguishable from magic from my perspective. At least at the
kernel-level.
Mark or others may be able to intervene and tell me I'm wrong, but it
seems like Java's NIO ("new IO") is nothing new: the standard C
library from 1970 contains the select() function which is exactly what
a Selector does. It takes a whole bunch of I/O channels and waits for
one of them to have activity, returning the set of channels with
activity that the caller can then handle.
Imagine writing "telnet" in Java with only java.io.InputStream and
java.io.OutputStream. First, you'd connect to the telnet server and
probably wait for some input like a password challenge, using
InputStream.read() for some reasonable time. But how do you know when
the "password prompt" is done? Maybe there is more input.
InputStream.read has a read-timeout, but it will block until there's
data or EOF (or timeout). There's no signalling that can be done from
server to client or vice versa.
Let's forget about login. What about sitting at command-line? Do you
sit there blocking on the InputStream listening for client input (e.g.
keyboard) or the InputStream from the server waiting for server input
(e.g. "System going down for maintenance in 10:00!")?
You just can't do it.
So with a Selector, you grab the channels for all those things (e.g.
keyboard, server), and say "hey, selector, I don't care whose ready
next, but let me know when something interesting happens". The
selector waits for EITHER the keyboard OR the server to provide input,
and then the thread waiting on the selector wakes up and gets the
message: "keyboard has data" and you handle it (probably by sending
that data to the server)". Or maybe it was "server has data" and you
print it to the screen. The point is that, with a Selector, you can
actually implement something like telnet where with, uh, "old IO" you
could not practically implement it.
This takes us back to the magic: for some reason, OS kernels need to
create a structure to use for the selector under the covers. [I did my
TCP/IP university work long ago, and don't ever remember discussing or
even noticing any domain socket being set up when a select() was being
called, but that may just be because it wasn't important to us at that
point -- an implementation detail.] Windows versus Linux choose to do
those things in different ways with different manifestations. Why do
they need it? Why did they choose those specific manifestations? I
have no idea. Go ask Ken Thompson or Dennis Richie (RIP). Or
serverfault. The information is out there. I can't give you a
canonical source myself.
If someone wants to provide a good reference, I'd love to read it myself
.
- -chris
> On 3/31/20, Christopher Schultz <ch...@christopherschultz.net>
> wrote: Frank,
>
> On 3/31/20 09:30, Frank Tornack wrote:
>>>> Yes, these too are for communication between processes. Only
>>>> you don't use the network stack. This is a special feature of
>>>> Unix-like operating systems.
>>>>
>>>> DGRAM, unlike STREAM, does not know connection states.
>>>> Therefore STREAM is comparable to a local TCP connection.
>>>> Unix domain sockets exist in the file tree as special files.
>>>> Access is controlled by file permissions, as is usual for
>>>> files.
>
> Yup. It's helpful to see the column headers for your netstat
> output, André:
>
>>>> Proto RefCnt Flags Type State I-Node
>>>> PID/Program name Path unix 2 [ ] STREAM
>>>> CONNECTED 167427210 27514/java unix 2 [ ]
>>>> STREAM CONNECTED 167423436 27514/java
>
> Each "unix" protocol-connection (UNIX domain socket) has an
> associated inode on the root filesystem, but no path. Basically,
> it's magic. :)
>
> The nice thing on *NIX is that even though there is a hand-wavy
> device supporting NIO for Java, it doesn't consume pairs of ports
> (which are a limited resource; see our recent discussion on the
> limits of TCP port numbers).
>
> -chris
>
>>>> Am Dienstag, den 31.03.2020, 14:29 +0200 schrieb André
>>>> Warnier (tomcat/perl):
>>>>> On 31.03.2020 14:20, Mark Thomas wrote:
>>>>>> On 31/03/2020 11:20, Aditya Kumar wrote:
>>>>>>> Tomcat 9.0.30 on Windows Server 2012 / Java 1.8
>>>>>>>
>>>>>>> I've noticed on a freshly installed version of tomcat
>>>>>>> 9, upon startup there are several connections to and
>>>>>>> from localhost on different ports
>>>>>>>
>>>>>>> For example on my tomcat server there are 4 connections
>>>>>>> to and from localhost (output from netstat)
>>>>>>>
>>>>>>>
>>>>>>> TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 3972
>>>>>>>
>>>>>>> TCP 127.0.0.1:55618 127.0.0.1:55619
>>>>>>> ESTABLISHED 3972
>>>>>>>
>>>>>>> TCP 127.0.0.1:55619 127.0.0.1:55618
>>>>>>> ESTABLISHED 3972
>>>>>>>
>>>>>>> TCP 127.0.0.1:55620 127.0.0.1:55621
>>>>>>> ESTABLISHED 3972
>>>>>>>
>>>>>>> TCP 127.0.0.1:55621 127.0.0.1:55620
>>>>>>> ESTABLISHED 3972
>>>>>>>
>>>>>>> TCP [::]:8080 [::]:0 LISTENING 3972
>>>>>>>
>>>>>>> These can grow to a large number (several thousand) on
>>>>>>> a busy system. What are these connections used for?
>>>>>>> What caused them? What thread are they attributed to?
>>>>>>
>>>>>> The Java NIO implementation on Windows uses TCP for
>>>>>> intra-process signalling. It opens a pair of
>>>>>> self-connected sockets for every Selector.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>
>>>>> While we're at it, under Linux, are the following for a
>>>>> similar reason ?
>>>>>
>>>>> output of : netstat -pan | grep 27514 (tomcat's JVM PID
>>>>> = 27514) [...] unix 2 [ ] STREAM
>>>>> CONNECTED 167427210 27514/java unix 2 [ ]
>>>>> STREAM CONNECTED 167423436 27514/java
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
- ---
>>>>>
>>>>>
>
>>>>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-h...@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
>
>>>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-h...@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6DeUMACgkQHPApP6U8
pFikSxAAobdKAfQ/3f48PiGHX/NvJlFDkmo3iv1yrUzNL4Dg7FqMtN5SbIRBv+9M
CgYpMVCWBhy2AGyMXNnmxNHgDy41+B+RvI7jRxVHCqeR+O+yxPMVwkPXQ3hVepQE
M72RwyaX89RkCIfsxTh5yIObbcpk+UgOtBKve5NMmW1E0o0GZG1qLJGq0qNdk5fD
ZAbguZHHf20PLSM2QeOZhrgQJu2mtTRpou2kMDV1OeYqYlyHfN2etowfm7E3G/KD
Pi2TPp2Ei7URdO2I5actbhMWdWFIGk1z/SCItMrmhEODdqLa2UK1wPUK11PCG1Wy
6/mDWbIg4+bY73NgaicQHC2CGpTbTmviFwZgYzx8u22FNhAE52WtvxeVzjLkmaTe
Wl/vz/3Y0S4pTFiaOgpoBUYEz3ln7bk3Znzex9FGa68uwQMQnxY5cFMggbyS0Bzt
VzWbkedeDnSq6xuhlgohZN4vPNU2c5Xq9Ys5Km8Hyg3oI3qBwYS+nUJQGcw6eIZB
+aLL1mQSOfuUbKFvzilQsrQMysoBOy1QlVQhhTnD0zdC2HVGWaWZZYz8CsSV5yum
O6IzZXGhKk5ZkxI5XEumkmnBC3j0zyN2qmiaIdK3PvwWGKdGZfGmsfsQek3AZLcx
WbcRkYRsvgHqm+Lwc8Ybv2fIUP9dkrtSMDTo+M3zMMuLR1RLJig=
=Uy1t
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
