I have written a simple server program which listens on port 4849. When I start it the first time everything works fine. If I stop and restart it, it fails:
Cannot bind!! ([Errno 98] Address already in use)
Netstat tells me this...
root#node2:/home/pi/woof# netstat -pl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:4849 *:* LISTEN 2426/dbus-daemon
tcp 0 *:* LISTEN 2195/sshd
....
What is dbus-daemon? Do I need it? Why is it listening on the port my server was listening on?
Thanks for any help.
Related
If I am writing constantly to a database and the following LOG message is displayed will any of the data I am writing by damaged or omitted?
LOG: using stale statistics instead of current ones because stats collector is not responding
No, this will not affect the integrity of data written to the database.
It just means that the statistics collector does not react fast enough, perhaps because of I/O overload.
You can probably get rid of the problem if you set stats_temp_directory to point to a directory in a RAM file system.
As already said in the previous answer, no it will not lose data. But you probably still want to fix the problem.
One possible cause for this problem is that the statistics collector process is bound to an IP:port which is not responding.
In such a case, restarting postgres will fix it.
This problem happened to me when I disabled IPv6 on the server without restarting Postgres. I eventually found a detailed explanation here (search for "The statistics collector" in the page), but in short:
PostgreSQL [...] will loop through all the addresses returned [for
localhost], create a UDP socket and test it until it has a socket
that works.
If the socket it had selected was IPv6 and it is later disabled, it stops working and you get that message in the logs.
You can check to which IP and UDP port the "postmaster" (or "postgres") service is bound with
netstat -n -u -p
The output is something like this:
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 127.0.0.1:47780 127.0.0.1:47780 ESTABLISHED 2824/postmaster
or on another host where it is bound to IPv6 ("udp6"):
# netstat -n -u -p
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp6 0 0 ::1:51761 ::1:51761 ESTABLISHED 1006/postgres
I have a question about the accept() function in C.
When a server receive a connection, the accept() function creates a new socket to communicate with the client, and then let the "old socket" listening for new connections.
Then, I understand that the server can communicate with the client through the "new socket", but how can the client communicate with the "new socket" (because the client don't know about this "new socket") ?
On the server side, the listening socket is associated with only a local IP and port and is in the LISTEN state.
In contrast, accepted sockets on the server (as well as connected sockets on the client) are identified by a local IP and port as well as a remote IP and port and is in the ESTABLISHED state.
On the client side, it doesn't matter that the server uses a listening socket separate from the connected socket. By the time the client returns from connect, the server has returned from accept and the socket descriptors returned from each can communicate with each other.
Any communication in IP protocol (including TCP/IP) occurs between two endpoints. The endpoints are always host:port. In the TCP world, the two endpoints identify the connection. A socket is associated with a connection, not with an endpoint.
Thus, you can have 2 sockets returned from 2 accept() calls, describing 2 distinct connections.
Here is an example of netstat -an output on a unix machine:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 170.44.26.7:22 161.231.133.178:11550 ESTABLISHED
tcp 0 0 170.44.26.7:22 161.231.133.178:33938 ESTABLISHED
tcp 0 0 170.44.26.7:22 161.231.133.178:13875 ESTABLISHED
tcp 0 0 170.44.26.7:22 161.231.133.178:34968 ESTABLISHED
tcp 0 0 170.44.26.7:22 161.231.133.178:44212 ESTABLISHED
tcp 0 0 170.44.26.7:22 161.231.133.178:34967 ESTABLISHED
Here we have a listening socket, and a few connections (each backed by its own socket) resulting from accept() on that socket.
Sockets are an abstraction of the network programming API. On the wire and for the client there is still only a single connection and the client does not see if the server is using a network API with listen, accept etc or if the server is using some other API or raw sockets to establish the connection.
The explanation is that a TCP (an end point in a TCP/IP transmission) is uniquely identified by the couple IPaddress/port_number. When a client asks for a connection, it does it using its IP and port number, a pair which is unique. That operation binds SRCIP+SRCPORT to DSTIP+DSTPORT, and those 4 numbers (the two IPs plus the two ports) uniquely identify a connection. So the two sockets on the server really refer to two different connections/streams.
I am beginner in TCP socket programming . I want to clarify some doubt about TCP programming concepts . I have a client and server program . This is my C code .
server code :
#define MYPORT 39937
struct sockaddr_in serveraddress,cliaddr;
sd = socket( AF_INET, SOCK_STREAM, 0 );
memset( &serveraddress, 0, sizeof(serveraddress) );
serveraddress.sin_family = AF_INET;
serveraddress.sin_port = htons(MYPORT);//PORT NO
serveraddress.sin_addr.s_addr = htonl(INADDR_ANY);//ADDRESS
retbind=bind(sd,(struct sockaddr*)&serveraddress,sizeof(serveraddress));
connfd=accept(sd,(struct sockaddr*)&cliaddr,&len);
client code :
struct sockaddr_in serveraddress;
sd = socket( AF_INET, SOCK_STREAM, 0 );
argv[1]//for ip address
argv[2]//for port
argv[3]//for string to send
memset( &serveraddress, 0, sizeof(serveraddress) );
serveraddress.sin_family = AF_INET;
serveraddress.sin_port = htons(atoi(V[2]));//PORT NO
serveraddress.sin_addr.s_addr = inet_addr(V[1]);//ADDRESS
if(connect(sd,(struct sockaddr*)&serveraddress,
sizeof(serveraddress)) < 0)
{
printf("Cannot Connect to server");
exit(1);
}
write(sd, V[3], strlen(V[3]));
I know that client program initialize the port and ipaddress of server . Is it true ? if it is true then why we use port and ipaddress inside server program ?
I am confused . another question why we don't use client port and ipaddress inside client program ? how server identifies this port and address of client machine ? Please Explain the entire concepts about server and client
I know that client program initialize the port and ipaddress of server . Is it true ?
The client app must specify the specific remote server IP/port to connect to, yes.
why we use port and ipaddress inside server program ?
A server app may specify a specific local port that it wants to listen on. If a port is not specified, the OS picks a random available port. Either way, this is the port that clients connect to.
The server machine may have multiple local IPs, if it is attached to multiple networks, so the server app may specify a specific local IP to listen on. If an IP is not specified, the server listens on all local IPs. This is used to control which network(s) clients are allowed to connect from.
why we don't use client port and ipaddress inside client program ?
You can, if you need to. This is optional.
A client machine may have multiple local IPs, if it is attached to multiple networks. The client may specify a specific local IP to connect from, if it knows the specific network connection that reaches the server. If an IP is not specified, the OS uses its internal routing tables to figure out which network to use and then connects from that local IP.
A client app may specify a local port that it wants to connect from. Some protocols require this, or a firewall/router policy may require it. If a port is not specified, the OS picks a random available port. Either way, this is the port that the client connects from.
how server identifies this port and address of client machine ?
accept() and getpeername() report the remote IP/port of a client that is communicating with the server.
Please Explain the entire concepts about server and client
There are entire books on that subject. It is out of scope for StackOverflow.
why we don't use client address inside TCP program?
Because we usually don't need to. See below.
I know that client program initialize the port and ipaddress of server. Is it true?
The client needs to know the IP address and port of the server, and use that to initialize a data structure to connect to it, but it isn't accurate to say that the client initializes anything of the server in any way.
If it is true then why we use port and ipaddress inside server program? I am confused.
The server needs to initialize its own IP address and port so that it can listen to it. The client needs to iniatialize another data structure in its own memory space to connect to the server. Just because it has the same name doesn't mean it is the same piece of memory.
another question why we don't use client port and ipaddress inside client program?
The client doesn't need to know its own address and port.
how server identifies this port and address of client machine?
It doesn't. It doesn't need to know. It has a socket which is connected to the client. In most cases that's all it needs. The client sends a request on the connection; the server replies over the same connection.
Please explain the entire concepts about server and client
Too broad.
This question already has answers here:
Does the port change when a server accepts a TCP connection?
(3 answers)
Closed 8 years ago.
If a TCP socket server listens on port 28081 for incoming connections and then accepts a connection and start receiving data. Is the port that data is coming into still 28081 or does the port get changed.
for example what port does the incoming data come to in the pseudo code below? Is it still 28081 or does the OS assign a new port?:
bind
listen (on port 28081)
while 1
fd = accept
fork
if child process incoming data
A TCP connection is uniquely identified by two (IP address, TCP port) tuples (one for each endpoint). So by definition, one can't move a port or IP address of a connection but just open a different one.
If the server binds to port 28081 all accepted connections will have this port on the server side (although they most likely will have varying port numbers on the client side).
For example, if two processes from the same client machine will connect to the same server, the IP address and TCP port on the server side will be the same for both connections. On the client side however, they will have two different port numbers allowing the operating system on both sides to uniquely identify which process and file descriptor the received TCP packets should be assigned to.
Yes, it stays on that port, though some protocols (FTP) might open a second connection on another port. Dont think of a port as a physical path or plug, like a USB port that can only have one thing plugged into it. But rather think of it as an identifier for the service being requested.
Often, though, the new socket connection is passed off to another thread which handles the read/writes for that specific connection.
There can be more than one client connecting to one port, as the connection is identified by both the server and client IP address and port. So, accepting the connection from one client does not block others from connecting. You could even connect another time from the same client (using another client port).
I'm trying to write a server program in C,
using another client, I get this error when I try to connect through port 2080 for example.
connection refused
What can be the reasons of this error?
There could be many reasons, but the most common are:
The port is not open on the destination machine.
The port is open on the destination machine, but its backlog of pending connections is full.
A firewall between the client and server is blocking access (also check local firewalls).
After checking for firewalls and that the port is open, use telnet to connect to the ip/port to test connectivity. This removes any potential issues from your application.
The error means the OS of the listening socket recognized the inbound connection request but chose to intentionally reject it.
Assuming an intermediate firewall is not getting in the way, there are only two reasons (that I know of) for the OS to reject an inbound connection request. One reason has already been mentioned several times - the listening port being connected to is not open.
There is another reason that has not been mentioned yet - the listening port is actually open and actively being used, but its backlog of queued inbound connection requests has reached its maximum so there is no room available for the inbound connection request to be queued at that moment. The server code has not called accept() enough times yet to finish clearing out available slots for new queue items.
Wait a moment or so and try the connection again. Unfortunately, there is no way to differentiate between "the port is not open at all" and "the port is open but too busy right now". They both use the same generic error code.
If you try to open a TCP connection to another host and see the error "Connection refused," it means that
You sent a TCP SYN packet to the other host.
Then you received a TCP RST packet in reply.
RST is a bit on the TCP packet which indicates that the connection should be reset. Usually it means that the other host has received your connection attempt and is actively refusing your TCP connection, but sometimes an intervening firewall may block your TCP SYN packet and send a TCP RST back to you.
See https://www.rfc-editor.org/rfc/rfc793 page 69:
SYN-RECEIVED STATE
If the RST bit is set
If this connection was initiated with a passive OPEN (i.e., came
from the LISTEN state), then return this connection to LISTEN state
and return. The user need not be informed. If this connection was
initiated with an active OPEN (i.e., came from SYN-SENT state) then
the connection was refused, signal the user "connection refused". In
either case, all segments on the retransmission queue should be
removed. And in the active OPEN case, enter the CLOSED state and
delete the TCB, and return.
Connection refused means that the port you are trying to connect to is not actually open.
So either you are connecting to the wrong IP address, or to the wrong port, or the server is listening on the wrong port, or is not actually running.
A common mistake is not specifying the port number when binding or connecting in network byte order...
Check at the server side that it is listening at the port 2080.
First try to confirm it on the server machine by issuing telnet to that port:
telnet localhost 2080
If it is listening, it is able to respond.
1.Check your server status.
2.Check the port status.
For example 3306 netstat -nupl|grep 3306.
3.Check your firewalls.
For example add 3306
vim /etc/sysconfig/iptables
# add
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
Although it does not seem to be the case for your situation, sometimes a connection refused error can also indicate that there is an ip address conflict on your network. You can search for possible ip conflicts by running:
arp-scan -I eth0 -l | grep <ipaddress>
and
arping <ipaddress>
This AskUbuntu question has some more information also.
I get the same problem with my work computer.
The problem is that when you enter localhost it goes to proxy's address not local address you should bypass it follow this steps
Chrome => Settings => Change proxy settings => LAN Settings => check Bypass proxy server for local addresses.
In Ubuntu, Try
sudo ufw allow <port_number>
to allow firewall access to both of your server and db.
From the standpoint of a Checkpoint firewall, you will see a message from the firewall if you actually choose Reject as an Action thereby exposing to a propective attacker the presence of a firewall in front of the server. The firewall will silently drop all connections that doesn't match the policy. Connection refused almost always comes from the server
In my case, it happens when the site is blocked in my country and I don't use VPN.
For example when I try to access vimeo.com from Indonesia which is blocked.
Check if your application is bind with the port where you are sending the request
Check if the application is accepting connections from the host you are sending the request, maybe you forgot to allow all the incoming connections 0.0.0.0 and by default, it's only allowing connections from 127.0.0.1
I had the same message with a totally different cause: the wsock32.dll was not found. The ::socket(PF_INET, SOCK_STREAM, 0); call kept returning an INVALID_SOCKET but the reason was that the winsock dll was not loaded.
In the end I launched Sysinternals' process monitor and noticed that it searched for the dll 'everywhere' but didn't find it.
Silent failures are great!