Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2007

Tip: Looking for answers? Try searching our database.

Choosing a network implementation strategy

Thread view: 
Qu0ll - 03 Dec 2007 12:38 GMT
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?

Signature

And loving it,

-Q
_________________________________________________
Qu0llSixFour@gmail.com
(Replace the "SixFour" with numbers to email me)

Gordon Beaton - 03 Dec 2007 12:47 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 - 3 lines]
> 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

--
Qu0ll - 03 Dec 2007 13:07 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 - 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/
Arne Vajhøj - 04 Dec 2007 03:34 GMT
> The basic architecture is an applet which communicates with a server
> over the internet, repeatedly reads instructions from the server and
[quoted text clipped - 6 lines]
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.