Communicating with a servlet using NIO?

[Qu0ll]

Is it possible for a client applet to communicate with a servlet using NIO?
I know it's possible using standard IO but I would like to implement a
servlet that accepts NIO connections from clients and interacts with them.
Is this possible? I don't want to use a special port because of firewall
considerations.

--
And loving it,

-Q
_________________________________________________
(e-mail address removed)
(Replace the "SixFour" with numbers to email me)

 

[Lew]

Is it possible for a client applet to communicate with a servlet using
NIO? I know it's possible using standard IO but I would like to
implement a servlet that accepts NIO connections from clients and
interacts with them. Is this possible? I don't want to use a special
port because of firewall considerations.

The choice of NIO or the older IO packages is independent between client and
server. It's just a connection.

Likewise the port choice is independent of how you use the port once chosen.
You'll use whatever port you choose. You choose whatever port you'll use.

 

[Andrew Thompson]

Lew wrote:
...

Likewise the port choice is independent of how you use the port once chosen.
You'll use whatever port you choose. You choose whatever port you'll use.

(A little out of my depth here*, but..) Would it not make most
sense to allow the end-user to select the (outgoing) port number
that best (dang well) suits them and their existing setup? [ Many
other apps. claim ports with no direct reference to the user's
wishes (probably according to clever algorithms that I would
prefer never to have to think/worry about). ]

Why would you do otherwise?

* My only minor messing with ports was in the Knock-Knock
server/client example - and of course, I leave it to the user to
decide what port numbers to use.
<http://www.physci.org/jws/#kk>

 

[Qu0ll]

The choice of NIO or the older IO packages is independent between client
and server. It's just a connection.

OK, but how do you do it exactly? What I'm trying to achieve is to do it
from an applet and not have the user have to select a port. The examples of
applet-2-servlet communication I can find use URLConnection but this only
has methods to get OutputStream etc. - nothing in relation to getting
SocketChannel or NIO-speak. Hence my original question as to whether it can
be done with NIO.

Likewise the port choice is independent of how you use the port once
chosen. You'll use whatever port you choose. You choose whatever port
you'll use.

I want to use the same port that HTTP uses so that there are no issues with
firewalls having to approve connections.

--
And loving it,

-Q
_________________________________________________
(e-mail address removed)
(Replace the "SixFour" with numbers to email me)

 

[Lew]

OK, but how do you do it exactly? What I'm trying to achieve is to do
it from an applet and not have the user have to select a port. The
examples of applet-2-servlet communication I can find use URLConnection
but this only has methods to get OutputStream etc. - nothing in relation
to getting SocketChannel or NIO-speak. Hence my original question as to
whether it can be done with NIO.

I suppose you could use the Socket class instead of URLConnection, but the
value of a channel on the client side is questionable. The point of NIO is to
multiplex several communications going through the same port. This will not
be an issue for a client. Why not just use the regular IO operations through
the URLConnection and just let the server do the NIO for its own sake?

What do you expect NIO will gain for you on the client side?

 

[Qu0ll]

I suppose you could use the Socket class instead of URLConnection, but the
value of a channel on the client side is questionable. The point of NIO
is to multiplex several communications going through the same port. This
will not be an issue for a client. Why not just use the regular IO
operations through the URLConnection and just let the server do the NIO
for its own sake?

Are you saying that I could have standard IO at the client end and NIO at
the server end? I didn't realise you could mix them that way. Do you have
an example of how that would work or could you explain it in a bit more
detail?

What do you expect NIO will gain for you on the client side?

Nothing really - I just thought that the client had to be NIO if the server
was NIO.

--
And loving it,

-Q
_________________________________________________
(e-mail address removed)
(Replace the "SixFour" with numbers to email me)

 

[Owen Jacobson]

Are you saying that I could have standard IO at the client end and NIO
at the server end? I didn't realise you could mix them that way. Do
you have an example of how that would work or could you explain it in a
bit more detail?


Nothing really - I just thought that the client had to be NIO if the
server was NIO.

Not at all. NIO is merely another way to talk to the IO subsystem of
the local host OS. Between hosts, it's all TCP/IP.

Once a sequence of bytes has been handed off to the OS to transmit over
a socket, there is nothing in that sequence of bytes identifying how it
was handed over; the stream {0x00, 0x01, 0x02, 0x03, ....} will look
identical to the receiver regardless of whether you use NIO to write it
or a Socket. What NIO does get you is the ability to multiplex IO
operations on a single thread. For applications with non-trivial
numbers of IO handles open at a time this matters; for programs that
only have one or two sockets, using a thread per socket is fine and
probably easier to read (if, possibly, harder to make thread-correct).

A client connecting to an NIO-based server would look identical to a
client connecting to any other server: new Socket ("192.168.0.1", 2700);

An NIO-based server accepting connections from a non-NIO client would
look identical to a server accepting connections from an NIO client:
someServerSocketChannel.accept ();

-o

 

[Gordon Beaton]

(A little out of my depth here*, but..) Would it not make most
sense to allow the end-user to select the (outgoing) port number
that best (dang well) suits them and their existing setup? [ Many
other apps. claim ports with no direct reference to the user's
wishes (probably according to clever algorithms that I would
prefer never to have to think/worry about). ]

It is extremely rare for the client's outgoing port to matter,
firewall or no. A "random" free port is used for virtually all
outgoing connections, and there is no need to consult the user about
this. A firewall that stops outgoing connections will normally do so
based on the *destination* port (i.e. where the server is listening).

On the other hand, the server's port needs to be known to the client
in advance, and can't be chosen by the client in any practical way.

/gordon

--

 

[Gordon Beaton]

I want to use the same port that HTTP uses so that there are no
issues with firewalls having to approve connections.

Of course that decision will force you to run your server on a host
that isn't already running a webserver. If the client is an applet,
then you will be forced to sign it or it will be unable to connect to
your service.

/gordon

--

 

[Nigel Wade]

Is it possible for a client applet to communicate with a servlet using NIO?
I know it's possible using standard IO but I would like to implement a
servlet that accepts NIO connections from clients and interacts with them.
Is this possible? I don't want to use a special port because of firewall
considerations.

A real firewall should do deep packet inspection which will ensure that the
traffic which is going over the "http" port is actually HTTP protocol. They do
this with the specific intent of blocking this type of port "hijacking".

Of course, if the firewalls in question are not commercial grade border
firewalls then you will probably get away with it. If they are then you might
well be wasting your time.

 

[George Neuner]

Lew wrote:
..

Likewise the port choice is independent of how you use the port once chosen.
You'll use whatever port you choose. You choose whatever port you'll use.

(A little out of my depth here*, but..) Would it not make most
sense to allow the end-user to select the (outgoing) port number
that best (dang well) suits them and their existing setup? [ Many
other apps. claim ports with no direct reference to the user's
wishes (probably according to clever algorithms that I would
prefer never to have to think/worry about). ]

It's impractical. Most users won't know what ports are in use or how
to find out. More importantly, you'd have to restrict the user's
selection to the set of free ports and the set of ports in use changes
constantly in a busy system. Not only do most programs let the system
select outgoing ports, but the system also selects the incoming ports
for most server programs.

When you select the listen port for your TCP (stream) server, you
haven't specified all the receive ports the program will use - the
total number of ports that may be used will include the backlog
parameter supplied to the listen() call (which, incidently, may be
silently reduced by the system). When a connection is made to a TCP
listen port, the system selects a free port and transfers the incoming
connection to it - all communication beyond the initial connection by
the client takes place through that randomly assigned port.

Peer services sometimes do send from known ports to distinguish their
own traffic from clients or other connection attempts, but in general
it's rarely necessary to pick outgoing ports for your program.

George

 

[Lew]

Peer services sometimes do send from known ports to distinguish their
own traffic from clients or other connection attempts, but in general
it's rarely necessary to pick outgoing ports for your program.

Furthermore, tying down the client port reduces another degree of freedom for
the system. Architecturally a program should only lock down the degrees of
freedom that it absolutely must in order to function correctly. The more it
can tolerate from the environment, i.e., ignore, the more robust the system.

Leaving client-side port selection to the client is smart. Leaving
client-side behavior in general to the client is smart.

 

[Esmond Pitt]

constantly in a busy system. Not only do most programs let the system
select outgoing ports, but the system also selects the incoming ports
for most server programs.

This is not correct. TCP/IP uses the same port number as the listening
port for incoming connections.

When a connection is made to a TCP
listen port, the system selects a free port and transfers the incoming
connection to it - all communication beyond the initial connection by
the client takes place through that randomly assigned port.

This is not correct. See above.

 

[George Neuner]

This is not correct. TCP/IP uses the same port number as the listening
port for incoming connections.


This is not correct. See above.

Sorry, but it is you who are wrong. Look in your help or man pages
for the description of the "accept" call.

You may be thinking that sockets can be shared and multiplexed - which
is true - but that's not how the accept call works.


<QUOTE> from FreeBSD man page accept(2)
Accept removes the next connection request from the queue (or waits
until a connection request arrives), creates a new socket for the
request, and returns the descriptor for the new socket. Accept only
applies to stream sockets (e.g., those used with TCP).
<\QUOTE>

<QUOTE> from Linux man page accept(2)
The accept() system call is used with connection-based socket types
(SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection
request on the queue of pending connections, creates a new connected
socket, and returns a new file descriptor referring to that socket.
The newly created socket is not in the listening state. The original
socket sockfd is unaffected by this call.
<\QUOTE>

<QUOTE> from Winsock2 SDK
The accept function extracts the first connection on the queue of
pending connections on socket s. It then creates and returns a handle
to a new socket. The newly created socket is the socket that will
handle the actual connection; it has the same properties as socket s,
including the asynchronous events registered with the WSAAsyncSelect
or WSAEventSelect functions.
<\QUOTE>


I don't have an AT&T Unix derivative handy to quote from its man page.
The basic TLI calls are similar to BSD in that t_listen sets the
connection point to passive mode and t_accept creates and returns a
new stream endpoint. The details are different because TLI allows
compositions of streams and filters in a way that's very similar to
the way Java handles streams.


In 20+ years I've worked with a half dozen versions of Unix, with
Linux, with MacOS (before the Unix versions), with every version of
Windows and with three different RTOS's. I've never encountered any
TCP implementation in which accept did not create a new socket.

George

 

[Lew]

Sorry, but it is you who are wrong. Look in your help or man pages
for the description of the "accept" call.

You may be thinking that sockets can be shared and multiplexed - which
is true - but that's not how the accept call works.


<QUOTE> from FreeBSD man page accept(2)
Accept removes the next connection request from the queue (or waits
until a connection request arrives), creates a new socket for the
request, and returns the descriptor for the new socket. Accept only
applies to stream sockets (e.g., those used with TCP).
<\QUOTE>

All of these references say "creates a new socket", none say "assigns a new port".

 

[George Neuner]

these references say "creates a new socket", none say "assigns a new port".

Oh shit, you're right. Geez ... I don't know what the hell I was
thinking. Sorry for the confusion.

George

 

[Lew]

these references say "creates a new socket", none say "assigns a new port".

Oh shit, you're right. Geez ... I don't know what the hell I was
thinking. Sorry for the confusion.

George, you are a hero to me now. I am being serious, not sarcastic. I
praise you and laud you.

Lots of people make mistakes. I've made worse mistakes in these newsgroups
than this one. Your forthrightness is a good example. Also, we cannot learn
unless we are willing to admit mistakes and change direction.

Bravo, George!