Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Linux netstat shows send and receive queue sizes.

How do I get this info under Windows, specifically Server 2003?

share|improve this question
    
Can you paste an example of the output you'd like to see? –  Izzy Sep 21 '09 at 20:02
    
Check out this link. I need the Recv-Q and Send-Q columns from netstat. linux-ip.net/html/tools-netstat.html –  Brien Sep 21 '09 at 20:14
add comment

6 Answers

(this is a bit of a brain dump)

From looking at a couple of versions of the netstat source, it seems like the information you're looking for is being queried directly from the kernel (/proc/net/...) not via socket-related calls that have Windows equivalents. If you're really determined to have this, I'd look at how it's being retrieved in netstat and see what you can find that provides something equivalent.

You should probably look at ndis.com (Network Driver Interface Specification) and PCAUSA.com for driver-level information, because that's likely to be your best place to retrieve this info on Windows.

I don't believe that getsockopt() or most of the Winsock arena is going to get you anywhere useful, but if you want to go that direction look at the MSDN Winsock information and also check out Winsock Programmer's FAQ.

For inbound, you may be able to get something useful from the ioctlsocket() function with FIONREAD to get the amount of readable data for a socket; you might not be able to get this across processes and depending on the type of data it may only return information for the first block of data not for the entire queue if there's more than one item queued.

You might do some digging on "backlog" in this context, but most of what I saw seemed to relate to setting the max size for dealing with SYN floods, not really with seeing how large the actual backlog was.

If you're really determined, you might be able to do something with your own Layered Service Provider, but that's a strange and ugly road full of perils and I'm going to suggest staying away from it.

UPDATE: After poking around a bit more, I definitely think you should look at querying NDIS OIDs. Finding the information most relevant to you is left as an exercise between you, MSDN and TechNet.

share|improve this answer
add comment

What you want might be the results of the WinSock API function calls getsockopt:

  • SO_RCVBUF The total per-socket buffer space reserved for receives. This is unrelated to SO_MAX_MSG_SIZE and does not necessarily correspond to the size of the TCP receive window.

  • SO_SNDBUF The total per-socket buffer space reserved for sends. This is unrelated to SO_MAX_MSG_SIZE and does not necessarily correspond to the size of a TCP send window.

The problem is that is can be asked for sockets whose handle you know. Querying from outside seems to be difficult, have a look at the sysinternals TcpView tool. Mark Russinovich is really a crack and even he does not provide the info in his tool. I am pretty sure he would have added a column if he had a mean to get the values easily...

I guess some kernel driver could help drilling down into the system but did not find any available tool. The sizes can be set on a per socket base so that global values have no meaning...

share|improve this answer
add comment

The closest thing I can find is the performance counter Network Interface\Output Queue Length. This isn't per-connection though - only per-interface and only covers the outbound queue (obviously, by it's name).

share|improve this answer
add comment

Now, the window sizes are different per socket! The settings per interface only represent the default-values.

I know of no way to view the window size of each socket. In Solaris, this can be seen with "netstat".

share|improve this answer
add comment

This question is old but I wanted to add some information. It's a fairly high search result on Google.

As far as I can tell there is not a way to do this, but if anyone can do more digging and figure out a valid alternative that would be much appreciated!

As @Fencepost pointed out in his answer, you can try to query NDIS OIDs. The most relevant NDIS OID I found is OID_GEN_TRANSMIT_QUEUE_LENGTH

Most of the NDIS OIDs are mapped to WMI classes, you can list them in powershell with

Get-WmiObject -Namespace root\wmi -List  | Where-Object {$_.name -Match "MSNdis" } | Sort-Object

but there doesn't seem to be one for Transmit Queue Length.

@Chris J mentioned Network Interface\Output Queue Length. You can get this value on the command line with typeperf.

typeperf "\Network Interface(*)\Output Queue Length" -sc 1

But the value is always 0: http://support.microsoft.com/kb/822226

Windows only keeps track of this information in the NIC driver software, and it's only packets queued per NIC, and doesn't distinguish between what's queued per socket.

If you do want to do network debugging on the command line, any counters you find in perfmon can be queried using typeperf or logman.

share|improve this answer
add comment

Have a look here: http://support.microsoft.com/kb/224829.

share|improve this answer
    
specifically, what am i supposed to be looking at there? –  Brien Sep 21 '09 at 19:46
    
Windows uses various algorithms to set its TCP receive window size; you can override the default by setting a Registry key. This program can also help you: dslreports.com/drtcp. –  Massimo Sep 21 '09 at 20:09
    
Massimo- you are confusing window sizes with queued data. I'm not interested in the window sizes. –  Brien Sep 21 '09 at 20:12
    
Ok, sorry. This information is not available in Windows, anyway. –  Massimo Sep 21 '09 at 21:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.