Communicating with a servlet using NIO?

Discussion in 'Java' started by Qu0ll, Dec 2, 2007.

  1. Qu0ll

    Qu0ll Guest

    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
    _________________________________________________

    (Replace the "SixFour" with numbers to email me)
    Qu0ll, Dec 2, 2007
    #1
    1. Advertising

  2. Qu0ll

    Lew Guest

    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
    Lew, Dec 2, 2007
    #2
    1. Advertising

  3. 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
    Andrew Thompson, Dec 2, 2007
    #3
  4. Qu0ll

    Qu0ll Guest

    "Lew" <> wrote in message
    news:...
    > 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
    _________________________________________________

    (Replace the "SixFour" with numbers to email me)
    Qu0ll, Dec 2, 2007
    #4
  5. Qu0ll

    Lew Guest

    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.
    Lew, Dec 2, 2007
    #5
  6. Qu0ll

    Qu0ll Guest

    "Lew" <> wrote in message
    news:...
    > 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
    _________________________________________________

    (Replace the "SixFour" with numbers to email me)
    Qu0ll, Dec 2, 2007
    #6
  7. On 2007-12-02 13:57:09 -0800, "Qu0ll" <> said:

    > "Lew" <> wrote in message
    > news:...
    >> 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
    Owen Jacobson, Dec 2, 2007
    #7
  8. 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, Dec 3, 2007
    #8
  9. 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

    --
    Gordon Beaton, Dec 3, 2007
    #9
  10. Qu0ll

    Nigel Wade Guest

    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 :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
    Nigel Wade, Dec 3, 2007
    #10
  11. On Sun, 02 Dec 2007 15:38:14 GMT, "Andrew Thompson" <u32984@uwe>
    wrote:

    >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
    --
    for email reply remove "/" from address
    George Neuner, Dec 4, 2007
    #11
  12. Qu0ll

    Lew Guest

    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
    Lew, Dec 4, 2007
    #12
  13. Qu0ll

    Esmond Pitt Guest

    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.
    Esmond Pitt, Dec 6, 2007
    #13
  14. On Thu, 06 Dec 2007 05:42:28 GMT, Esmond Pitt
    <> 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>

    <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
    --
    for email reply remove "/" from address
    George Neuner, Dec 7, 2007
    #14
  15. Qu0ll

    Lew Guest

    George Neuner wrote:
    > On Thu, 06 Dec 2007 05:42:28 GMT, Esmond Pitt
    > <> 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
    Lew, Dec 8, 2007
    #15
  16. On Fri, 07 Dec 2007 20:47:53 -0500, Lew <> wrote:

    > 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
    --
    for email reply remove "/" from address
    George Neuner, Dec 9, 2007
    #16
  17. Qu0ll

    Lew Guest

    >> 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
    Lew, Dec 9, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MattC
    Replies:
    0
    Views:
    440
    MattC
    Nov 24, 2004
  2. circuit_breaker
    Replies:
    2
    Views:
    1,989
    Jack Jia
    Apr 4, 2004
  3. iksrazal

    NIO with timeouts != NIO?

    iksrazal, Jun 17, 2004, in forum: Java
    Replies:
    1
    Views:
    6,231
    iksrazal
    Jun 18, 2004
  4. Michael Sparks
    Replies:
    3
    Views:
    318
  5. Laurent Verweijen

    Communicating with a program using subprocess

    Laurent Verweijen, Jun 17, 2010, in forum: Python
    Replies:
    1
    Views:
    677
    Nobody
    Jun 19, 2010
Loading...

Share This Page