 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2006socket, how to know the port is used by my app
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? -- Thanks John > Hi, > [quoted text clipped - 7 lines] > Thanks > John 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. > Hi, > [quoted text clipped - 3 lines] > > 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.  Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | > > Hi, > > [quoted text clipped - 10 lines] > gregorie. | Essex, UK > org | 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? -- John >>> Hi, >>> [quoted text clipped - 18 lines] > 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. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | >> How about in the java code itself? let's say, same java app executed >> twice, [quoted text clipped - 3 lines] >> > 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. :D > 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 [quoted text clipped - 3 lines] > 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. > 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 Signature[ don't email me support questions or followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e > 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. Free MagazinesGet 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 ...
|
Reply to this Message
|
 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
|
©2008 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.