Application is using MSMQ services.
But some remote workstations cannot have MSMQ TCP connection established properly with server.
execute netstat -ano|findstr (msmq port), there is not TCP connection either in SYN-SENT or ESTABLISHED state from server to remote workstations.
But after restart MSMQ services in server and remote workstation, then TCP connection can be found and established.
Any suggestions?
Thank you
I assume that the remote workstations are available for some time before becoming unavailable (network outage, maybe). MSMQ uses a retry mechanism to re-establish contact with the remote workstations. While the destination is unavailable and connection attempts continue to fail, the retry mechanism waits for longer and longer periods before new attempts are made. After the destination becomes available again, MSMQ won't know until a connection is attempted when the next retry interval is reached. Restarting MSMQ services resets the retry interval to zero and connections are immediately established.
Related
Can you describe the main process with TCP connection status?
In fact I'm more concerned about whether those connections that have been established can be closed after the client receives a proper reply from the server ...... That's part of the graceful shutdown, I think.
The accepted connections are totally independent of the listening socket. So the server can stop listening and the accepted sockets can still be used as if nothing happened. This means that each accepted socket has it's own tcp connection state (diagram).
Often, though, servers stop listening when they are shut down, so they close all sockets at that time.
I am working in a legacy VB6 project that involves TCP Communication using sockets.
Application requires long lived socket connections but i doubt to how much extent it is possible.
Application runs in windows OS.
If after a socket connection in established and some data is exchanged at regular intervals say 30 sec,
will the connection lives forever or is there any constraints from OS or TCP stack or network provider?
There is no technical limitation against having a TCP socket connected for months on end.
Skype will have a 24/7 TCP session established to a server as long as it's running.
The idea of TCP is that you:
syn→
← synack
ack→
And now your connection is established. Barring some technical issue (rebooted machines), that TCP connection will stay up forever. Yes there may be various edge firewalls that have to maintain stateful information about that TCP/IPv6 (or TCP/IPv4) connection - but that is the firewall's problem.
Their job is to route traffic. If they can't handle n open connections: then they need to be redesigned.
I know that the TCP is connection oriented. But if I set up a forwarding server(syslog server for example) which forwards logs on TCP, is the connection always on or whenever the logs are forwarded to a server.
It depends on the server configuration.
Say you are working on Linux, you can use the command
cat /proc/sys/net/ipv4/tcp_keepalive_time
to check your current keepalive value in seconds.
On its documentation ( https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns ) for Logical DNS service discovery, Envoy says:
"only uses the first IP address returned when a new connection needs to
be initiated"
How does envoy decide when a new upstream connection needs to be initiated?
It also says:
"Connections are never drained"
What happens to old connections if an upstream host becomes unreachable? Do health-checks apply to all the upstream hosts that currently have established connections or are they only monitoring the host with the current "first IP address"? If the latter, am I right to assume that Envoy will only remove the failed upstream connection (and consequently stop trying to send traffic to those hosts) once it tries to write to it and the peer ACK times out? If so, is it possible to configure the timeout duration?
After looking into the code and doing some tests this is what I've seen:
How does envoy decide when a new upstream connection needs to be
initiated?
For connection establishment, in the case of the TCP proxy (the filter I was using), there is a 1:1 mapping between downstream and upstream connections, therefore a new upstream connection is established when a new downstream connection is established.
What happens to old connections if an upstream host becomes
unreachable?
It depends on whether the connection was gracefuly terminated (TCP RST packet sent) or not. If it was, then the connection will be destroyed (along with the downstream connection), if it was not, then nothing happens until the TCP connection times out (I believe due to TCP_USER_TIMEOUT or tcp_retries2 retries - it was taking more than 15 minutes on my local machine).
Do health-checks apply to all the upstream hosts that currently have
established connections or are they only monitoring the host with the
current "first IP address"?
They only apply to the current "first IP address".
If the latter, am I right to assume that Envoy will only remove the
failed upstream connection (and consequently stop trying to send
traffic to those hosts) once it tries to write to it and the peer ACK
times out?
Yes. Typically the downstream clients timeouts will kick in first and destroy the connection though.
If so, is it possible to configure the timeout duration?
I couldn't find an option to set the socket's TCP_USER_TIMEOUT in envoy. Changing the OS tcp_retries2 might help, but, according to the documentation, the total time is also influenced by the smoothed round trip time of the TCP connection, so a change to tcp_retries2 wouldn't be able to define an absolute timeout value.
While a tcp client is connecting to a tcp server, and at same time the Listening port at server side hasn't been established. At this time will the tcp client report connection refused exception or connection time out exception ?
At first I think a connection refused exception will be reported by tcp/ip, because the server could check if the LISTEN port( which is connected by client) is exist. But actually a connection time out instead.
I am wondering if tcp/ip protocol has explained such a situation?
At this time will the tcp client report connection refused exception or connection time out exception ?
If the client gets an active refusal, i.e. a TCP RST segment, this shows up at the client as ECONN. Otherwise you get a connection timeout. Note that this can also include the case where an intermediate firewall prevented the connection, as it is usually considered more secure not to leak the information that the host even exists if firewall rules prevent connecting to that port.