linux拒绝从本地主机打开监听端口

Question

I have problem to open a listening port from localhost in a heavy loaded production system.

Sometimes some request to my port 44000 failed. During that time , I checked the telnet to the port with no response, I'm wonder to know the underneath operations takes there. Is the application that is listening to the port is failing to response to the request or it is some problem in kernel side or number of open files.

I would be thankful if someone could explain the underneath operation to opening a socket.

Let me clarify more. I have a java process which accept state full connection from 12 different server.requests are statefull SOAP message . this service is running for one year without this problem. Recently we are facing a problem that sometimes connection from source is not possible to my server in port 44000. As I checked During that time telnet to the service is not possible even from local server. But all other ports are responding good. they all are running with same user and number of allowed open files are much more bigger than this all (lsof | wc -l )

As I understood there is a mechanism in application that limits the number of connection from source to 450 concurrent session, And the problem will likely takes when I'm facing with maximum number of connection (but not all the time)

My application vendor doesn't accept that this problem is from his side and points to os / network / hardware configuration. To be honest I restarted the network service and the problem solved immediately for this special port. Any idea please???

Answer 1

Here's a quick overview of the steps needed to set up a server-side TCP socket in Linux:

1. socket() creates a new socket and allocates system resources to it (*)
2. bind() associates a socket with an address
3. listen() causes a bound socket to enter a listening state
4. accept() accepts a received incoming attempt, and creates a new socket for this connection. (*)

(It's explained quite clearly and in more detail on wikipedia ).

(*) : These operations allocate an entry in the file descriptor table and will fail if it's full. However, most applications fork and there shouldn't be issues unless the number of concurrent connections you are handling is in the thousands (see, the C10K problem ).

If a call fails for this or any other reason, errno will be set to report the error condition (eg, to EMFILE if the descriptor table is full). Most applications will report the error somewhere.

---

Back to your application, there are multiple reasons that could explain why it isn't responding. Without providing more information about what kind of service you are trying to set up, we can only guess. Try testing if you can telnet consistently, and see if the server is overburdened.

Cheers!

Answer 2

Your description leaves room for interpretation, but as we talked above, maybe your problem is that your terminated application is trying to re-use the same socket port, but it is still in TIME_WAIT state.

You can set your socket options to reuse the same address (and port) by this way:

int srv_sock;
int i = 1;

srv_sock = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(srv_sock, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i));

Basically, you are telling the OS that the same socket address & port combination can be re-used, without waiting the MSL (Maximum Segment Life) timeout. This timeout can be several minutes.

This does not permit to re-use the socket when it is still in use, it only applies to the TIME_WAIT state. Apparently there is some minor possibility of data coming from previous transactions, though. But, you can (and should anyway) program your application protocol to take care of unintelligible data.

More information for example here: http://www.unixguide.net/network/socketfaq/4.5.shtml

Answer 3

Start TCP server with sudo will solve or, in case, edit firewalls rules (if you are connecting in LAN). Try to scan ports with nmap (like with TCP Sync Handshake), or similar, to see if the port is opened to any protocol (maybe network security trunkates pings ecc.. to don't show hosts up). If the port isn't responsive, check privileges used by the program, check firewalls rules maybe the port is on but you can't get to it.

Mh I mean.. you are talking about enterprise network so I'm supposing you are on a LAN environment so you are just trying to localhost but you need it to work on LAN. Anyway if you just need to open localhost port check privileges and routing, try to "tracert" and see what happens and so on...

Oh and check if port is used by a higher privilege service or deamon.

Anyway I see now that this is a 2014 post, np gg nice coding byebye