socket, how to know the port is used by my app

[John_Woo]

Hi,

if there are several java app (other app) in a machine occupying some
ports, and a few of them are java app using ports for Socket Server
(those app pickup randomly a port from a fixed range).

I'm wondering, how to know which port is used by my java app?

 

[Mark Space]

Hi,

if there are several java app (other app) in a machine occupying some
ports, and a few of them are java app using ports for Socket Server
(those app pickup randomly a port from a fixed range).

I'm wondering, how to know which port is used by my java app?

Normally, when you create a user port, the OS picks it, and it chooses
one that is not in use, so you are good.

If you require a specific port, that should be configured by your
Administrator, and read in by your app as part of it's configuration.
It's the administrator's responsibility to make sure two apps aren't
configured on the same port.

For example, on my FreeBSD system, ports are configured in
/etc/services, and to a lesser extant /etc/protocols. Even the echo
protocol, which everyone knows runs on port 7, is still configured in
/etc/services, so I could change it to any port if I really wanted too.

You need to decide how and who you want to configure your ports, then
read the ports out of that configuration repository. Allow for command
line and local config too, just for convenience. Most Java apps have
some sort of XML file in their .jar for configuration, but don't
overlook the convenience of having all network config in one spot like
/etc/services.

If you are just testing, just choose one you know you aren't using.

 

[Martin Gregorie]

Hi,

if there are several java app (other app) in a machine occupying some
ports, and a few of them are java app using ports for Socket Server
(those app pickup randomly a port from a fixed range).

I'm wondering, how to know which port is used by my java app?

Run lsof on the server and grep its output for the name of your app.

 

[John_Woo]

Run lsof on the server and grep its output for the name of your app.

Thanks, Martin,

How about in the java code itself? let's say, same java app executed
twice,
A - the first executed; B - the second executed.
Both A & B pick up a port from a list, then how do they tell each other
which port it uses?

 

[Martin Gregorie]

Thanks, Martin,

How about in the java code itself? let's say, same java app executed
twice,
A - the first executed; B - the second executed.
Both A & B pick up a port from a list, then how do they tell each other
which port it uses?

That's a somewhat different question from the one you originally asked.

All types of socket provide a getLocalPort() method to get their own
port number and the Socket class, used by clients, can use getPort() to
get the remote port. What your app does with the information is up to
you. For instance, it might write it to a file, store it in a database
table or send it to a server with a known host name and port that other
apps can query.

You seem to be talking about a set of servers which each listens on an
unused port chosen randomly from a range of ports. I must say that this
is a remarkably bad idea. Why go out of your way to make life hard?
Follow the standard: assign each server a known port to listen on. Each
incoming connection is accepted (by the accept() method which clones the
connection) and passed to a thread that handles the connection until it
is closed.

The listener port number can then be published and documented in
/etc/services. If there could be a clash with another server, its
trivial to make the listener port number configurable via a config file,
read from /etc/services or passed in as a command line argument.

 

[Mark Space]

That's a somewhat different question from the one you originally asked.

Yup, but it was obvious he was going here, so I gave the real answer
right off the bat.

All types of socket provide a getLocalPort() method to get their own
port number and the Socket class, used by clients, can use getPort() to
get the remote port. What your app does with the information is up to
you. For instance, it might write it to a file, store it in a database
table or send it to a server with a known host name and port that other
apps can query.

I don't know if this is automatic in TCP/IP or not, but there's a common
idiom where a server listens on a well-known port (ie., one you publish
in /etc/services) and when it receives a request from a client, grabs a
new port (randomly) and responds to the client with that new port #. It
keeps the main port clear for new connections.

You seem to be talking about a set of servers which each listens on an
unused port chosen randomly from a range of ports. I must say that this
is a remarkably bad idea. Why go out of your way to make life hard?
Follow the standard: assign each server a known port to listen on. Each
incoming connection is accepted (by the accept() method which clones the
connection) and passed to a thread that handles the connection until it
is closed.

Ditto. The new port stuff I mention above would be handled by the new
thread in the example quoted above.

The listener port number can then be published and documented in
/etc/services. If there could be a clash with another server, its
trivial to make the listener port number configurable via a config file,
read from /etc/services or passed in as a command line argument.

Ditto, and good advice.

Final advice: get some basic networking books and learn how this works.
It ain't Java, it's TCP/IP. Java just implements an API for you.

 

[Gordon Beaton]

I don't know if this is automatic in TCP/IP or not, but there's a common
idiom where a server listens on a well-known port (ie., one you publish
in /etc/services) and when it receives a request from a client, grabs a
new port (randomly) and responds to the client with that new port #. It
keeps the main port clear for new connections.

TCP does no such thing automatically or otherwise. Some poorly written
applications may do so, but it's hardly a common idiom.

The original listening port does not need to be "kept clear". Incoming
connections can and do share the same port number as the original
listening socket. There is no conflict, it creates no extra work for
the server, and each connection uses a completely distinct socket.

/gordon

 

[EJP]

I don't know if this is automatic in TCP/IP or not, but there's a common
idiom where a server listens on a well-known port (ie., one you publish
in /etc/services) and when it receives a request from a client, grabs a
new port (randomly) and responds to the client with that new port #. It
keeps the main port clear for new connections.

Surely you mean 'thread' not 'port' throughout in the above? There is no
need for a new port and no such idiom I am aware of. Unless you are
talking about FTP which is another kettle of fish entirely.