>> 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
[quoted text clipped - 7 lines]
> 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.)

Signature
And loving it,
-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)
Gordon Beaton - 03 Dec 2007 13:12 GMT
> 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
--
Qu0ll - 03 Dec 2007 13:21 GMT
>> 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
[quoted text clipped - 11 lines]
>
> 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?

Signature
And loving it,
-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)
Gordon Beaton - 03 Dec 2007 13:28 GMT
> 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
--
Matt Humphrey - 03 Dec 2007 13:41 GMT
>>> 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
[quoted text clipped - 13 lines]
> 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/