I am making a UPD socket application based on winsock. However, I cant figure out how to check if server socket is closed or not. I try to use recvfrom but it still return sent data even when the program closed. Is there anyway to check if a socket is closed or not.
I'm working on a big server in C++ where we provide service to multiple users. I noticed recently that after some cases in my code, sockets are not closed properly and we have thousands of them in the state CLOSE_WAIT. I read what this mean
CLOSE_WAIT Indicates that the server has received the first FIN
signal from the client and the connection is in the process of being
closed
So this essentially means that his is a state where socket is waiting
for the application to execute close()
A socket can be in CLOSE_WAIT state indefinitely until the application
closes it. Faulty scenarios would be like filedescriptor leak, server
not being execute close() on socket leading to pile up of close_wait
sockets
I'm starting to search where is my bug because it's clear that we are not closing properly these sockets.
What implies for my program memory having all these sockets in CLOSE_WAIT state? I noticed that when I have a lot of these sockets the process start to consume a lot of memory (4GB). Which implications in relation with memory have this? Maybe this memory leak is not related with this? Thank you very much.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Send buffer empty of Socket in Linux?
I want to create a socket server sending some data to a connecting client and disconnect him again.
I'm using non-blocking sockets so I don't know how to figure out if all data have at least been sent (send?) correctly (in short: no more data in my send buffer).
I don't want to keep the connection established if it's not neccessary anymore because I can't ensure that the client disconnects on his own.
Currently I'm just shutting down the client using shutdown() and later close(). But testing showed me a client does not always recieve all data before the connection gets closed.
There must be a way to ensure all data got send before closing the connection on non-blocking sockets, too, isn't there? Hope my question is clear enough and you can help me (:
The only way you can know your data has been sent prior to ending the connection is for the peer to acknowledge it in the application protocol. You can ensure that both ends get to EOS at the same time by shutting down for output at both ends and then reading to EOS at both ends, then closing the socket at both ends.
you can send the file size prior to data of the file. While closing the socket just check the file size and take appropriate action to close or resend the file....
I have a C++ application called A which open a TCP connection to Application B.
Application C knows about this connection and can close the socket from B side.
My question is:
how can I know if the connection has closed in proper closing, or it is the network connection problem?
Currently I have a timeout which knows when there is no receive, but this not indicate about a proper closing or network connection problem.
I heard that since it is a TCP connection if application C close the connection properly the OS must know about it, do you know how can I know in application A that the connection has closed properly?
if you can attach a c++ sample it will be helpful.
If the connection was closed properly, recv() will return zero. If it was closed improperly, recv() will eventually timeout (although there can be other reasons for that), and send() will eventually return -1 with errno ECONNRESET or whatever it's called.
I have a UDP file descriptor in a C++ program running under Linux. I call connect() on it to connect it to a remote address and then read and write from that socket.
According to UNIX Network Programming, "Asynchronous errors are returned to the process for connected UDP sockets." I'm guessing that these asynchronous errors will cause the UDP socket to be closed by the OS, but the book isn't that clear. It also isn't clear what types of asynchronous errors are possible, though it's suggested that if the port on the remote machine is not open, the socket will be closed.
So my question is: Under what conditions will Linux close the UDP file descriptor?
Bad port number?
Bad IP address?
Any others?
connect() on an UDP socket just records the port number and IP address you pass in, so it'll only accept packets from that IP/port, and you can use the socket fd to send/write data without specifying the remote address for each send/write call.
Regarding this, async errors means if you send() something, and that send call results in an error occuring later (e.g. when the TCP/IP stack actually sends the packet, or an ICMP packet is later returned), a subsequent send will return that error. Such async errors are only returned on a "connected" UDP socket. (The linux udp(7) manpage suggest errors are returned whether the socket is connected or not, but testing shows this is not the cases at least when a sent UDP packet generates an ICMP error. It might be that send() errors are returned if you recv() on that socket, instead of subsequent send() calls produce an error )
The socket is not closed though, you'll have to close it yourself either by calling close() or exiting the program. e.g. if you connect() your UDP socket, and send to a port noone is listening to, an ICMP packet is normally returned and a subsequent send() call will fail with errno set to ECONNREFUSED. You can continue sending on that socket though, it doesn't get closed by the OS, and if someone starts listening on the port in the mean time the packets will get through.
UDP sockets are connectionless, so there is no real sense of "openness" state attached to them - this is unlike TCP sockets where a socket may be in any number of connection states as determined by the exchange of packets up to a given point.
The only sense in which UDP sockets can be opened and closed is in the sense that they are system level objects with some internal state and a file descriptor. Sockets are never automatically closed in the event of an error and will remain open indefinitely, unless their owning process terminates or calls close on them.
To address your other concern, if the destination port on the destination host is not opened, the sender of a UDP packet will never know.** UDP provides no means of receiver acknowledgement. The packet is routed and, if it arrives at the host, checked for correctness and either successfully received or discarded. There are a number of reasons why send might return an error code when writing to a UDP socket, but none of them have to do with the state of the receiving host.** I recommend consulting the sendto manpage for possible failure modes.
On the other hand, in the case of a TCP socket attempting to connect to an unopened port, the sender will never receive an acknowledgement of its initial connection request, and ultimately connect will fail. At this point it would be up to the sender to stop sending data over the socket (as this will only generate more errors), but even in this case however, the socket file descriptor is never automatically closed.
** See response by #Zuljin in the comments.
The OS won't close your socket just because an error has happened. If the other end disappears, you can continue to send messages to it (but may receive further errors).