How can I see/monitor TCP connections in backlog queue on Windows Server?
Any tools or PS scripts or anything else to monitor the queue in real time would be appreciated.
I searched around, didn't find anything useful.
Related
What exactly does it actually do?
If I do -P 100 on the client side,
Does it open 100 ports and make 100 connections to a given server in parallel?
Is it what's normally used to simulate a server maintaining "X (simultaneous) connections in parallel"?
Note: this answer is iperf 2 related. iperf 3 is single threaded.
Yes, if the client computer supports threads there will be 100 traffic threads and 1 reporter thread. The traffic threads will send traffic to the server threads "in parallel" and the reporter thread will output statistics to stdout per the -i value. How much "in parallel" depends upon CPU cores and OS scheduling. More cores can allow more traffic threads to truly run in parallel. When the cores are exhausted the threads will be scheduled by the underlying OS scheduler. (Note: In 2.0.8 or greater and with Linux, the traffic threads can be set to realtime scheduling using -z or --realtime.)
Bob
Can anyone tell me how a server offer concurrent TCP services to multiple clients
while using only a single thread?
Thanks very much !!
It uses a physical thread provided by the system, but it is able to create as many virtual treads as the system allows/supports(usually one thread per request), assuming a single threaded system, which is pretty uncommon on today servers configurations, and a X86 arch, each thread would get a bit of processor time on each clock run enabling the server to work with multiple requests at "virtually" the same time.
Regards.
I need a program which monitors network traffic. But like this way: It will show running processes and which IPs and websites are they getting/sending packets. I had such program, but I can't find nor remember its name. All programs I find on google searches returns me same program style which only monitors general network traffic.
You can use wireshark on packet level. Netstat on port level (local).
to monitor a network:
put a port on the switch as monitor port, and put the device in promiscious mode.
use wireshark to see the traffic.
(wireshark was ethereal in the past)
You can try LSP or WinpCap monito process traffic。
I hope this may be helpful to you.
The program you need depends on the type of architecture. If you have devices supporting Netflow, this could be very handy to identify bottlenecks or missues. There are just a few good tools for netflow under a low budget, try solarwinds or Pandora FMS.
For SNMP monitoring, probably the most common case, most tools do a good job: cacti, zabbix, pandora fms or nagios. OpenNMS and Pandora FMS have the best management of Traps, and only a few manage v3 properly.
For a mixed scope on monitoring: server, apps and networking, you have less tools, we use Pandora FMS for that reason, can manage netflow, snmp, wmi (for remote server monitoring) and agent based monitoring for unix & windows server.
Some links:
http://pandorafms.com/Producto/network-monitoring/en
http://opems.org
Our software includes a module to stream live video data to multiple clients. Most of time it works fine, but in some cases it seems to have caused some malfunction of windows network.
When it happens, the LAN connection status in network connections still says "connected", and the IP address is normal. But I cannot ping any other device in the network. The only way to fix it is to disable and then re-enable the network connection.
This problem seems to be OS-independent, it has happened on XP, Vista and Win7 machines.
Has anyone experienced anything similar? Did my application crashed the network stack? or is it something else?
More likely a fault with the networking switch unless you have a really bad NIC.
Cheapest route is to first replace the NIC, but ideally you should be able to reproduce the fault in a test harness so try with a direct crossover cable between two hosts first to rule out the networking infrastructure being at fault.
∴ Server Fault could be a better place to ask the question.
I am to design a server that needs to serve millions of clients that are simultaneously connected with the server via TCP.
The data traffic between the server and the clients will be sparse, so bandwidth issues can be ignored.
One important requirement is that whenever the server needs to send data to any client it should use the existing TCP connection instead of opening a new connection toward the client (because the client may be behind a firewall).
Does anybody know how to do this, and what hardware/software is needed (at the least cost)?
What operating systems are you considering for this?
If using a Windows OS and using something later than Vista then you shouldn't have a problem with many thousands of connections on a single machine. I've run tests (here: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html) with a low spec Windows Server 2003 machine and easily achieved more than 70,000 active TCP connections. Some of the resource limits that affect the number of connections possible have been lifted considerably on Vista (see here: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html) and so you could probably achieve your goal with a small cluster of machines. I don't know what you'd need in front of those to route the connections.
Windows provides a facility called I/O Completion Ports (see: http://msdn.microsoft.com/en-us/magazine/cc302334.aspx) which allow you to service many thousands of concurrent connections with very few threads (I was running tests yesterday with 5000 connections saturating a link to a server with 2 threads to process the I/O...). Thus the basic architecture is very scalable.
If you want to run some tests then I have some freely available tools on my blog that allow you to thrash a simple echo server using many thousands of connections (1) and (2) and some free code which you could use to get you started (3)
The second part of your question, from your comments, is more tricky. If the client's IP address keeps changing and there's nothing between you and them that is providing NAT to give you a consistent IP address then their connections will, no doubt, be terminated and need to be re-established. If the clients detect this connection tear down when their IP address changes then they can reconnect to the server, if they can't then I would suggest that the clients need to poll the server every so often so that they can detect the connection loss and reconnect. There's nothing the server can do here as it can't predict the new IP address and it will discover that the old connection has failed when it tries to send data.
And remember, your problems are only just beginning once you get your system to scale to this level...
This problem is related to the so-called C10K problem. The C10K page lists a large number of good resources for addressing the problems you will encounter when you try to allow thousands of clients to connect to the same server.
I've come across the APE Project
a while back. It seems like a dream come true. They can support up to 100k concurrent clients on a single node. Spread them across 10 or 20 nodes, and you can serve millions. Perfect for RESTful applications. Might want to look deeper for any shared namespace. One drawback is that this is a standalone server, as in supplementary to a web server. This server is of course Open Source, so any cost is hardware/ISP related.
You cannot use UDP. If the client sends a request and you don't reply immediately, a router is going to forget the reverse route in 30 seconds or less, so your server will never be able to reply to the client.
TCP is the only option, and it, too, will give you headaches. Most routers are going to forget the route and/or drop the connection after a few minutes, so your client/server code is going to have to send "keep alives" fairly often.
I recommend setting up a "sniffer", to see how the phone companies are staying in touch with your smartphone for their "push" technology. Copy whatever they're doing, because that stuff works!
As Greg mentioned, the problem you are describing is C10K (or rather "C1M" in your case )
I recently made a simple TCP echo server on linux that scales very well with the number of sessions (only tested up to 200.000 though), by using the epoll queue. On BSD, you have something similar called kqueue.
You can check out the code if you want to. Hope this helps and good luck!
EDIT: As noted in the comments below, my original assertion that there is a 64K limit based on the number of ports is incorrect, however there is a 32K limit on the number of socket handles, so my suggested design is valid.
With a typical TCP/IP server design, you're limited in the number of simultaneous open connections you can have. The server has one listening port, and when a client connects to it the server makes an accept call, and that creates a new socket on a random port for the rest of the connection.
To handle more than 64K simultaneous connections I think you need to use UDP instead. You only need one port for the server to listen on, and you need to manage the connections using a 32-bit client ID in the packet data instead of having a separate port for each client. The 32-bit client ID could be the client's IP address, and the client can listen on a known UDP port for messages coming back from the server. That port would be the only one that needs to be open on the firewall.
With this approach, your only limitation is how quickly you can handle and respond to UDP messages. With millions of clients, even sparse traffic could give you large spikes, and if you don't read the packets fast enough your input queue will fill up and you'll start dropping packets. The C10K page Greg points to will give you strategies for that.