Linux netstat affiche les tailles de file d'attente d'envoi et de réception.
Comment obtenir ces informations sous Windows, en particulier Server 2003?
Linux netstat affiche les tailles de file d'attente d'envoi et de réception.
Comment obtenir ces informations sous Windows, en particulier Server 2003?
Réponses:
(c'est un peu une décharge de cerveau)
En regardant quelques versions de la source netstat, il semble que les informations que vous recherchez sont interrogées directement depuis le noyau (/ proc / net / ...) et non via des appels liés aux sockets qui ont des équivalents Windows. Si vous êtes vraiment déterminé à avoir cela, je regarderais comment il est récupéré dans netstat et voir ce que vous pouvez trouver qui fournit quelque chose d'équivalent.
Vous devriez probablement consulter ndis.com (Network Driver Interface Specification) et PCAUSA.com pour des informations au niveau du pilote, car c'est probablement votre meilleur endroit pour récupérer ces informations sur Windows.
Je ne pense pas que getsockopt () ou la plupart de l'arène Winsock vous rendra utile, mais si vous voulez aller dans cette direction, consultez les informations MSDN Winsock et consultez également la FAQ du programmeur Winsock .
Pour les communications entrantes, vous pourrez peut-être obtenir quelque chose d'utile à partir de la fonction ioctlsocket () avec FIONREAD pour obtenir la quantité de données lisibles pour un socket; il se peut que vous ne puissiez pas obtenir cela entre les processus et selon le type de données, il peut ne renvoyer des informations pour le premier bloc de données que pour la file d'attente entière s'il y a plus d'un élément en file d'attente.
Vous pourriez faire quelques recherches sur le «backlog» dans ce contexte, mais la plupart de ce que j'ai vu semblait concerner la définition de la taille maximale pour traiter les inondations SYN, pas vraiment pour voir la taille réelle du backlog.
Si vous êtes vraiment déterminé, vous pourriez peut-être faire quelque chose avec votre propre fournisseur de services en couches , mais c'est une route étrange et laide pleine de dangers et je vais suggérer de rester à l'écart.
MISE À JOUR: Après avoir fouillé un peu plus, je pense vraiment que vous devriez envisager d'interroger les OID NDIS. Trouver les informations les plus pertinentes pour vous est laissé comme un exercice entre vous, MSDN et TechNet.
Cette question est ancienne mais je voulais ajouter quelques informations. C'est un résultat de recherche assez élevé sur Google.
Pour autant que je sache, il n'y a pas moyen de le faire, mais si quelqu'un peut creuser davantage et trouver une alternative valable, ce serait très apprécié!
Comme @Fencepost l'a souligné dans sa réponse, vous pouvez essayer d'interroger les OID NDIS. L'OID NDIS le plus pertinent que j'ai trouvé est OID_GEN_TRANSMIT_QUEUE_LENGTH
La plupart des OID NDIS sont mappés à des classes WMI, vous pouvez les répertorier dans PowerShell avec
Get-WmiObject -Namespace root\wmi -List | Where-Object {$_.name -Match "MSNdis" } | Sort-Object
mais il ne semble pas y en avoir un pour la longueur de la file d'attente de transmission.
@Chris J a mentionné Interface Network \ Output Queue Length. Vous pouvez obtenir cette valeur sur la ligne de commande avec typeperf .
typeperf "\Network Interface(*)\Output Queue Length" -sc 1
Mais la valeur est toujours 0: http://support.microsoft.com/kb/822226
Windows ne garde la trace de ces informations que dans le logiciel du pilote NIC, et ce ne sont que des paquets mis en file d'attente par NIC, et ne fait pas de distinction entre ce qui est mis en file d'attente par socket.
Si vous souhaitez effectuer le débogage réseau sur la ligne de commande, tous les compteurs que vous trouvez dans perfmon peuvent être interrogés à l'aide de typeperf ou logman .
Ce que vous voulez peut être les résultats des appels de fonction de l'API WinSock getsockopt
:
SO_RCVBUF
Espace tampon total par socket réservé pour les réceptions. Ceci n'est pas lié à SO_MAX_MSG_SIZE
et ne correspond pas nécessairement à la taille de la fenêtre de réception TCP.
SO_SNDBUF
Espace tampon total par socket réservé aux envois. Ceci n'est pas lié à SO_MAX_MSG_SIZE
et ne correspond pas nécessairement à la taille d'une fenêtre d'envoi TCP.
Le problème est qu'on peut demander des sockets dont vous connaissez la poignée. Interroger de l'extérieur semble être difficile, jetez un œil à l' outil sysinternals TcpView . Mark Russinovich est vraiment un crack et même lui ne fournit pas les informations dans son outil. Je suis à peu près sûr qu'il aurait ajouté une colonne s'il avait eu un moyen d'obtenir facilement les valeurs ...
Je suppose qu'un pilote de noyau pourrait aider à explorer le système mais n'a trouvé aucun outil disponible. Les tailles peuvent être définies sur une base par socket afin que les valeurs globales n'aient aucune signification ...
Jetez un œil ici: http://support.microsoft.com/kb/224829 .