From: markspace on
LC's No-Spam Newsreading account wrote:

> I initially see a connection from my http-alt to some arbitrary
> port on her system (which my lsof decodes with funny names like
> cogitate, tomato-springs, or other names each time different).


As John pointed out, these are registered ports. However, that means
little, your system can re-use the port numbers with out problems. I'm
surprised lsof is bothering to list ports by name, there's only a very
small chance this information will be useful.

I think these "funny names" are just a red-herring and not relevant to
your problem at all.

>
> Any obvious suggestion that this behaviour might be due to a
> Windows/Linux incompatibility ? Or to a bug in my code (but it did work
> with other Linux users) ?


What I'm seeing mostly here is a lack of any sort of log file or other
actual debugging mechanism. Dumping port connections is fine to
establish that the software can talk, but it doesn't actually tell us
anything, or at least doesn't tell me anything. You should make some
kind of log of the session that you can review. This is the only way
that I know of short of attaching a debugger.

It could be a compatibility problem. Java mostly gets around that, but
clever programmers can still find lots of ways to introduce bugs.

Since you've established that the systems can connect (open ports), I
think the next step is to add some debugging information to the servlet
to dump session information, so you can have some hope of debugging the
problem (adding logs to the applet will be harder). Assume it's
software and debug from that point of view. Bonus points if the logs
can be changed per user, so you don't have to write reams of logs for
other users that are working correctly.
From: LC's No-Spam Newsreading account on
On Thu, 17 Dec 2009, markspace wrote:
> LC's No-Spam Newsreading account wrote:

>> I initially see a connection from my http-alt to some arbitrary
>> port on her system (which my lsof decodes with funny names like
>> cogitate, tomato-springs, or other names each time different).
>
> As John pointed out, these are registered ports. However, that means
> little, your system can re-use the port numbers with out problems.

Not sure about the technical meaning of "registered ports". I assumed
lsof is translating port numbers into whatever finds in /etc/services.

What puzzled me is that if I run the "foreign application" (i.e. the
applet) locally, I see its ports are some arbitrary high numbered port
(which seems fine to me). When the applet runs remotely, I see the odd
names (which according to /etc/services are relatively low numbered
ports) ... so I suppose it is the remote system which is offering such
port number for the client sockets.

> I think these "funny names" are just a red-herring and not relevant to
> your problem at all.

Essentially you are saying that using such low numbered registered
ports is harmless. Correct ?

Is http-alt something which java (or JSDK/jsdk2.1 servlets) does
routinely use when listening on a server socket ?

> What I'm seeing mostly here is a lack of any sort of log file or other
> actual debugging mechanism. Dumping port connections is fine to
> establish that the software can talk [...] Since you've established
> that the systems can connect (open ports)

well, on one hand I've established more than that. Not only ports are
open, but the servlet can respond correctly to the simple handshake
protocol I designed when the remote client is a manual telnet session on
the designated port.

On the other hand, I do have logging facilities :

- I start the servlet in a dedicated account ssh'd in a dedicated
window. The servlet writes to System.out all what it is doing.
So I can see there what it does.

- The servlet duplicates the same information to the out stream of
the http request. So the remote user can see (in the left hand
frame of the frameset) what the servlet is doing.

- the applet is a rather complex arrangement (a tabbed pane with an
image area, a JTable, several controls AND a scrollable message
area. I have a button which enables verbose messages, so that the
applet wirtes to the message area what it is doing.

The point is that all this shows things are working perfectly when I run
the applet locally. When it is run remotely simply it gets stuck at some
point.

So I FIRST had the logging, and since that did not give me any clue, I
did lsof port monitoring.

The other peculiarity I can mention is that the applet runs natively in
my (rather old) firefox on Linux, while my remote user had to install
some java plugin to run it in her firefox on Windows.


--
----------------------------------------------------------------------
nospam(a)mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
From: Lew on
LC's No-Spam Newsreading account wrote:
> The other peculiarity I can mention is that the applet runs natively in
> my (rather old) firefox on Linux, while my remote user had to install
> some java [sic] plugin to run it in her firefox on Windows.

Java doesn't run natively. Your Firefox already had the plugin, that's all.

--
Lew
From: markspace on
LC's No-Spam Newsreading account wrote:

> Essentially you are saying that using such low numbered registered
> ports is harmless. Correct ?


Port numbers should not matter. It's just a port. If you can talk on
it at all, then it's fine.

> The point is that all this shows things are working perfectly when I run
> the applet locally. When it is run remotely simply it gets stuck at some
> point.


You need to find more precisely what that point is. I don't think a log
window for the user to look at is going to help here. You'll need finer
grained info. Either use a SocketHandler in you app to send logs
directly to the server, or write logs to a file and ask the client to
upload (or email) them to you.

After that, the next step is to attach a debugger directly to the remote
system and step through the code yourself.