«

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)

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" <> 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)

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" <> 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)

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

--

"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/

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