Choosing a network implementation strategy

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

  1. Qu0ll

    Qu0ll Guest

    The basic architecture is an applet which communicates with a server over
    the internet, repeatedly reads instructions from the server and behaves in
    an appropriate manner (i.e. displays text on the screen). The reads from
    the server are triggered by user actions in the applet. The key design
    objective is to have the lag between when the user initiates the action to
    when they see a result on the screen (a result of interaction with the
    server) as small as possible.

    So, to the possible implementations... I have identified at least 3 namely
    NIO client and server, RMI client and server and applets/servlets.

    I have implemented a solution with NIO and it works technically speaking but
    I am not entirely happy with the lag. It has the pros that it's a highly
    scalable solution but I am wondering if I can do better. It has one con
    that I can think of in that it has to use a hard-code port and if that port
    is already in use on the client machine then bad luck! Also, accessing that
    port may have firewall/security issues.

    So then there's RMI. I am hoping that perhaps this will result in less lag.
    It has the pro that it's simple to code. It has the same cons as the NIO
    solution namely hard-code port and firewall/security issues.

    Then there's applets/servlets. This has the distinct advantage that the
    port used is the standard HTTP port. I am not sure about the lag though.

    Of course I could build an implementation of each and measure the
    performance but I am hoping a bit of friendly advice will direct me straight
    to the best solution. Which implementation is likely to produce the
    smallest lag? Is there another (better) implementation? Any other
    comments?

    --
    And loving it,

    -Q
    _________________________________________________

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

  2. On Mon, 3 Dec 2007 23:38:18 +1100, Qu0ll wrote:
    > I have implemented a solution with NIO and it works technically
    > speaking but I am not entirely happy with the lag. It has the pros
    > that it's a highly scalable solution but I am wondering if I can do
    > better. It has one con that I can think of in that it has to use a
    > hard-code port and if that port is already in use on the client
    > machine then bad luck! Also, accessing that port may have
    > firewall/security issues.


    Why do you think you need to reserve a port on the *client* machine?
    This is rarely necessary, firewall or not. Why should it be necessary
    with NIO, but not the other mechanisms you mention?

    /gordon

    --
     
    Gordon Beaton, Dec 3, 2007
    #2
    1. Advertising

  3. Qu0ll

    Qu0ll Guest

    "Gordon Beaton" <> wrote in message
    news:4753fac9$0$3518$...
    > On Mon, 3 Dec 2007 23:38:18 +1100, Qu0ll wrote:
    >> I have implemented a solution with NIO and it works technically
    >> speaking but I am not entirely happy with the lag. It has the pros
    >> that it's a highly scalable solution but I am wondering if I can do
    >> better. It has one con that I can think of in that it has to use a
    >> hard-code port and if that port is already in use on the client
    >> machine then bad luck! Also, accessing that port may have
    >> firewall/security issues.

    >
    > Why do you think you need to reserve a port on the *client* machine?
    > This is rarely necessary, firewall or not. Why should it be necessary
    > with NIO, but not the other mechanisms you mention?


    OK, perhaps it's a problem with my understanding... if I setup my server to
    use port 54321 then I need to hard code into the applet to contact the
    server on port 54321... if that port is being used on the client machine,
    won't that be a problem? Or are you saying that it's only an issue on the
    *server* machine?

    Either way, isn't it possible that the firewall on the client may not like
    the applet communicating over port 54321 which it knows nothing about?

    (I did mention that the RMI solution has the same (perceived) problem of the
    hard coded port as the NIO solution.)

    --
    And loving it,

    -Q
    _________________________________________________

    (Replace the "SixFour" with numbers to email me)
     
    Qu0ll, Dec 3, 2007
    #3
  4. On Tue, 4 Dec 2007 00:07:42 +1100, Qu0ll wrote:
    > OK, perhaps it's a problem with my understanding... if I setup my
    > server to use port 54321 then I need to hard code into the applet to
    > contact the server on port 54321... if that port is being used on
    > the client machine, won't that be a problem? Or are you saying that
    > it's only an issue on the *server* machine?


    The port number only needs to be unique on the server, where it is
    used to direct the incoming connections to the correct service (your
    server application).

    > Either way, isn't it possible that the firewall on the client may
    > not like the applet communicating over port 54321 which it knows
    > nothing about?


    Yes, that's possible, independent of which mechanism you choose.

    /gordon

    --
     
    Gordon Beaton, Dec 3, 2007
    #4
  5. Qu0ll

    Qu0ll Guest

    "Gordon Beaton" <> wrote in message
    news:475400b5$0$3512$...
    > On Tue, 4 Dec 2007 00:07:42 +1100, Qu0ll wrote:
    >> OK, perhaps it's a problem with my understanding... if I setup my
    >> server to use port 54321 then I need to hard code into the applet to
    >> contact the server on port 54321... if that port is being used on
    >> the client machine, won't that be a problem? Or are you saying that
    >> it's only an issue on the *server* machine?

    >
    > The port number only needs to be unique on the server, where it is
    > used to direct the incoming connections to the correct service (your
    > server application).
    >
    >> Either way, isn't it possible that the firewall on the client may
    >> not like the applet communicating over port 54321 which it knows
    >> nothing about?

    >
    > Yes, that's possible, independent of which mechanism you choose.


    OK thanks Gordon. Do you have any thoughts on the best solution for reduced
    lag?

    --
    And loving it,

    -Q
    _________________________________________________

    (Replace the "SixFour" with numbers to email me)
     
    Qu0ll, Dec 3, 2007
    #5
  6. On Tue, 4 Dec 2007 00:21:07 +1100, Qu0ll wrote:
    > Do you have any thoughts on the best solution for reduced lag?


    What lag, exactly? How have you observed it?

    Perhaps it's as simple as maintaining an open connection for the
    duration of the client session, instead of connecting once for each
    message?

    Ultimately any mechanism you choose will be based on TCP sockets.
    "Traditional" SocketStreams and NIO are two mechanisms that add no
    additional overhead, so any latency that is not already due to the
    network is caused by your application (too many layers, encoding
    complexity, things like that). Latency that is due to the network will
    be there regardless of your choice.

    /gordon

    --
     
    Gordon Beaton, Dec 3, 2007
    #6
  7. "Qu0ll" <> wrote in message
    news:4753ff9e$0$22901$...
    > "Gordon Beaton" <> wrote in message
    > news:4753fac9$0$3518$...
    >> On Mon, 3 Dec 2007 23:38:18 +1100, Qu0ll wrote:
    >>> I have implemented a solution with NIO and it works technically
    >>> speaking but I am not entirely happy with the lag. It has the pros
    >>> that it's a highly scalable solution but I am wondering if I can do
    >>> better. It has one con that I can think of in that it has to use a
    >>> hard-code port and if that port is already in use on the client
    >>> machine then bad luck! Also, accessing that port may have
    >>> firewall/security issues.

    >>
    >> Why do you think you need to reserve a port on the *client* machine?
    >> This is rarely necessary, firewall or not. Why should it be necessary
    >> with NIO, but not the other mechanisms you mention?

    >
    > OK, perhaps it's a problem with my understanding... if I setup my server
    > to use port 54321 then I need to hard code into the applet to contact the
    > server on port 54321... if that port is being used on the client machine,
    > won't that be a problem? Or are you saying that it's only an issue on the
    > *server* machine?


    It's only an issue on the server. A client can choose any port that's
    available on its end. (And availability will depend on how many client
    connections are in operation at any one time.) Furthermore, multiple
    clients can all access the same server port simultaneously because
    connections are identified by 4 pieces of information:
    IP address of the receiver, the port of the receiver
    IP address of the sender, the port of the sender

    The client port really just distinguishes multiple senders on the same
    receiver.

    >
    > Either way, isn't it possible that the firewall on the client may not like
    > the applet communicating over port 54321 which it knows nothing about?


    Firewalls normally block *incoming* connection requests and requests to
    particular outgoing ports (eg. only allow connections to services (servers)
    on ports 80, 22, 23) The choice of client port number doesn't affect the
    connection or service--any port would do just fine so these (typically)
    aren't restricted. When creating a client socket, just let the TCP stack
    choose the port for you--usually by selecting 0.

    Matt Humphrey http://www.iviz.com/
     
    Matt Humphrey, Dec 3, 2007
    #7
  8. Qu0ll

    Arne Vajhøj Guest

    Qu0ll wrote:
    > The basic architecture is an applet which communicates with a server
    > over the internet, repeatedly reads instructions from the server and
    > behaves in an appropriate manner (i.e. displays text on the screen).
    > The reads from the server are triggered by user actions in the applet.
    > The key design objective is to have the lag between when the user
    > initiates the action to when they see a result on the screen (a result
    > of interaction with the server) as small as possible.
    >
    > So, to the possible implementations... I have identified at least 3
    > namely NIO client and server, RMI client and server and applets/servlets.


    You are mixing up a lot of things:

    RMI, HTTP and plain sockets are protocols that can be used

    for plain sockets you can use the traditional java.io API or
    the new java.nio API

    applet is a client application type and can use all 3 protocols

    servlet is a server application type that by definition use
    HTTP protocol

    Arne
     
    Arne Vajhøj, Dec 4, 2007
    #8
    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. Kal
    Replies:
    1
    Views:
    9,532
    Kevin Spencer
    Jun 21, 2004
  2. Jane Davis

    Network Service account over network

    Jane Davis, Jun 22, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    453
    Kevin Spencer
    Jun 22, 2005
  3. Bill Volk
    Replies:
    1
    Views:
    3,155
    Bill Volk
    Jul 2, 2003
  4. kin
    Replies:
    0
    Views:
    919
  5. Obtice

    help on choosing a strategy

    Obtice, Nov 10, 2011, in forum: VHDL
    Replies:
    12
    Views:
    1,404
    jeppe
    Nov 13, 2011
Loading...

Share This Page