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
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Lew

Qu0ll wrote:
> 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.

--
Lew

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>

--
Andrew Thompson
http://www.physci.org/

Message posted via http://www.javakb.com

Qu0ll

"Lew" <lew@lewscanon.com> wrote in message
news:tcSdnVyTpb-5Vs_anZ2dnUVZ_jOdnZ2d@comcast.com...
> Qu0ll wrote:
>> 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.

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
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Lew

Qu0ll wrote:
> 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?

--
Lew
This post contained two requests for information.

Qu0ll

"Lew" <lew@lewscanon.com> wrote in message
news:w86dne2nkKwgus7anZ2dnUVZ_jKdnZ2d@comcast.com. ..
> Qu0ll wrote:
>> 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?

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
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Owen Jacobson

On 2007-12-02 13:57:09 -0800, "Qu0ll" <Qu0llSixFour@gmail.com> said:

> "Lew" <lew@lewscanon.com> wrote in message
> news:w86dne2nkKwgus7anZ2dnUVZ_jKdnZ2d@comcast.com. ..
>> Qu0ll wrote:
>>> 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?
>
> 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.

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

On Sun, 02 Dec 2007 15:38:14 GMT, Andrew Thompson wrote:
> (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

On Mon, 3 Dec 2007 07:10:14 +1100, Qu0ll wrote:
> 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

Qu0ll wrote:

> 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.

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555