Communicating with a servlet using NIO?

java-programmer, Communicating with a servlet using NIO? 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
_________________________________________________
email***@***.com
(Replace the "SixFour" with numbers to email me)

java-programmer >> Communicating with a servlet using NIO? 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

java-programmer >> Communicating with a servlet using NIO? 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

java-programmer >> Communicating with a servlet using NIO? "Lew" <email***@***.com> wrote in message
news:email***@***.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
_________________________________________________
email***@***.com
(Replace the "SixFour" with numbers to email me)

java-programmer >> Communicating with a servlet using NIO? 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.

java-programmer >> Communicating with a servlet using NIO? "Lew" <email***@***.com> wrote in message
news:email***@***.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
_________________________________________________
email***@***.com
(Replace the "SixFour" with numbers to email me)

java-programmer >> Communicating with a servlet using NIO? On 2007-12-02 13:57:09 -0800, "Qu0ll" <email***@***.com> said:

> "Lew" <email***@***.com> wrote in message
> news:email***@***.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

java-programmer >> Communicating with a servlet using NIO? 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 : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> Communicating with a servlet using NIO? George Neuner wrote:
> 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.

--
Lew

java-programmer >> Communicating with a servlet using NIO? George Neuner wrote:

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

java-programmer >> Communicating with a servlet using NIO? George Neuner wrote:
> On Thu, 06 Dec 2007 05:42:28 GMT, Esmond Pitt
> <email***@***.com> wrote:
>
>> George Neuner wrote:
>>
>>> 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.
>
> 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".

--
Lew

java-programmer >> Communicating with a servlet using NIO? >> these references say "creates a new socket", none say "assigns a new port".

George Neuner wrote:
> 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!

--
Lew