I would like to know what happen to TCP connections when a windows user logs off and another user logs in on the same computer. Will the tcp connections created by user 1 be closed or it will be yet open in the background.
Thanks
Connections depend on processes. Usually when logging off, user-initiated processes and their TCP connections are closed.
You can keep processes and connections open by switching users instead of logging off and on again.
Related
I'm writing a DLL for a purchased software.
The software will perform multi-threaded calculations on certain tasks.
My job is to output the relative result into a database.
However, due to the limited support of the software, it is kind of difficult to do multi-threaded output of the data.
The key problem is that there is no info on the last execution of the DLL function.
Therefore, the database connection will not be closed.
So may I ask if I leave the connection open and terminate the process, what would be the potential problems?
My platform is winserver 2008, and PostgreSQL 10.
I don't understand the background information you are giving, but I can answer the question:
If a PostgreSQL client process dies without closing the database (and TCP) connection, the PostgreSQL server process (“backend process”) that servers this connection will not realize this immediately.
Of course, as soon as the server tries to communicate to the client, e.g. to return some results, TCP it will notice that the partner has gone away and will return an error.
However, often the backend process is idle, waiting for the client to send the next request. In this case, it would never notice that its partner has died. This could eventually cause max_connections to be exhausted with dead connections.
Because this is a common problem in networking, TCP provides the “keepalive” functionality: when a connection has been idle for a while (2 hours by default), the operating system will send a so-called “keepalive packet” and wait for a response from the other side. Sending keepalive packets is repeated several times (5 times by default) in short intervals (1 second by default), and if no response is received, the connection is closed by the operating system, the backend process receives an error message and terminates.
PostgreSQL provides parameters with which you can configure these settings on the server side: tcp_keepalives_idle, tcp_keepalives_count and tcp_keepalives_interval. If you set tcp_keepalives_idle to a shorter value, dead connections will be detected and removed faster, at the cost of some little added network traffic.
Im fairly new to Tmux but from what I've read, its using a client-server connection.
Why is that neccessary? Is that only for managing sessions? Why does it communicate through a socket rather than directly with the client?
If anyone could provide me an explanation, that would be appreciated.
Thanks.
Tmux requires a server that is able to keep located the processes when a session is detached.
If you run a process with the "nohup" or "disown" the process in going to run in background even when user logout, however the problem is to recover the control of the process when the user login again.
Tmux server keep those processes associated, so when you login and the user attach the session again. Tmux server is able to MUltipleX several Terminal sessions among other things.
All the magic of Tmux in made by the server, but you don't have to be afraid of Tmux server because, the Tmux server is not running as a general system daemon, the Tmux server is launched from the userspace individually, and when not user sessions are allocated Tmux server automatically stop itself, this is the reason why when you type "tmux ls" and sessions were not previously created the message "failed to connect to server: Connection refused" is displayed (The server is not running, hereby connection is refused).
Is it possible that windows leaks sockets connection and these sockets are not shown in tcpview and netstat?
After running a few applications that perform many network connections, my windows machine enters a state in whitch it in not able to open any new socket connection. Even to itself (localhosts).
For example, telnet to a local application failed because windows can't create new sockets.
Closing and restarting the network applications does not helps. Only full windows restart solves the problem.
netstat (& tcpview) indicates that there are only some dozens of connections.
Thanks for your help.
No, it is not possible for those apps to miss leaked connections. Something else is going on. Maybe you are not looking at their detailed views, like seeing closed sockets that are in TIME_WAIT state. If you cannot open new socket connections, you mostly likely are encountering port exhaustion. Wait some time for ports to time out and become available again. Or stop wasting ports in the first place.
I am trying to reverse engineer a third-party TCP client / server Windows XP, SP 3 app for which I have no source available. My main line of attack is to use WireShark to capture TCP traffic.
When I issue a certain GUI command on the client side, the client creates a TCP connection to the server, sends some data, and tears down the connection. The server port is 1234, and the client port is assigned by the OS and therefore varies.
WireShark is showing that the message corresponding to the GUI command I issued gets sent twice. The two messages bear a different source port, but they have the same destination port (1234, as mentioned previosuly).
The client side actually consists of several processes, and I would like to determine which processes are sending these messages. These processes are long-lived, so their PIDs are stable and known. However, the TCP connections involved are transient, lasting only a few milliseconds or so. Though I've captured the client-side port numbers in WireShark and though I know all of the PIDs involved, the fact the connections are transient makes it difficult to determine which PID opened the port. (If the connections were long-lived, I could use netstat to map port numbers to PIDs.) Does anybody have any suggestions on how I can determine which processes are creating these transient connections?
I can think of two things:
Try sysinternals' tcpview program. It gives a detailed listing of all tcp connections opened by all the processes in the system. If a process creates connections, you will be able to see them flash (both connect and disconnect are flashed) in tcpview and you will know which processes to start looking into.
Try running the binary under a debugger. Windbg supports multi-process debugging (so does visual studio I think). You may have only export symbols to work with but that should still work for calls made to system dlls. Try breaking on any suspected windows APIs you know will be called by the process to create the connections. MSDN should have the relevant dlls for most system APIs documented.
Start here... post a follow-up if you get stuck again.
I ended up creating a batch file that runs netstat in a tight loop and appends its output to a text file. I ran this batch file while running the system, and by combing through all of the netstat dumps, I was able to find a dump that contained the PIDs associated with the ports.
I had some networking issues on my Windows server, and find out (by using NETSTAT) that I have more than 90,000 (!) connections in TIME_WAIT which didn't closed.
I've changed the TcpTimedWaitDelay param in registry, but apparently a server restart is needed.
Because it's a single production DB server, I can't afford it at the moment.
Is there any way killing a TIME_WAIT connection?
Any other suggestions?
Thanks!
Roei
I have more than 90,000 (!) connections in TIME_WAIT which didn't closed.
No you don't. These represent connections which have already closed, and whose local port is hanging around for TCP security reasons. They will only be that way for a couple of minutes each. Just wait.