Je veux recevoir un paquet TCP brut puis le renvoyer avec la même charge de travail.
Il devrait ressembler à ceci comme suit: P>
void OnPacketReceived(TcpPacket p)
{
byte [] body = p.GetBody();
}
3 Réponses :
Si vous implémentez la prise sous forme de prise brute, vous avez accès à tout le paquet (et doit en fait gérer tout ce qui vous concerne le paquet vous-même).
Utilisez sockettype.raw et protocoltype.raw lors de la création de la prise.
Sachez simplement que vous allez avoir à gérer les détails de TCP si vous implémentez votre prise de cette façon.
Pour référence, voici la documentation MSDN sur la classe Socket: http://msdn.microsoft.com/en-us /Library/system.net.sockets.socket.aspx
+1: J'ai utilisé cette méthode pour vérifier si l'en-tête de paquet TCP a une somme de contrôle ou non (car ce n'est pas obligatoire).
@Tallonguralnek Pourriez-vous partager le code s'il vous plaît? ou au moins pour décrire ce qui doit être fait pour atteindre cela?
@DODEXAHEDRON - Êtes-vous 100% positif que si je connecte le socket RAW, j'ai accès au paquet TCP directement? (C'est en fait la question). Si vous êtes sûr, pouvez-vous confirmer cela et je la marque comme la réponse. Merci.
Oui. Notez que l'ouverture d'une prise de cette manière dans .NET nécessite des autorisations d'administrateur (doit exécuter l'application en tant qu'administrateur, à Vista +) ou vous obtiendrez une exception. Vous aurez accès à l'ensemble du paquet en tant que réseau d'octets, lors de l'utilisation d'une prise brute, vs juste la charge utile, lors de l'utilisation d'une prise TCP.
Réalisez également que, comme je l'ai dit, vous devez mettre en œuvre TCP pour que cela fonctionne. La poignée de main ne sera même pas manipulée pour vous, plus.
Vous devez utiliser Packet Sniffer où vous pouvez mettre des filtres de votre choix et sur la base de cela peut également répondre.
.NET wrapper autour de WinPCAP peut s'avérer utile pour vous.
Vous pouvez utiliser la bibliothèque PCAPDototNet.
Bibliothèque utile, merci pour une suggestion. :)
Je pourrais être 100% faux, mais je ne suis pas sûr que cela soit possible avec le code géré. Autant que je sache la bibliothèque de socket en C # utilise des flux exclusivement, résumant ainsi les limites des paquets.
Permet de voir si quelqu'un aurait pu craquer cela.
Avez-vous regardé pcapdotnet.codeplex.com C'est un wrapper .NET autour de WinPCAP.
Oui. Mais c'est pourquoi j'ai demandé spécifiquement TCP pas Ethernet. Je ne veux pas écrire mes propres NDIS et je ne veux pas d'un sniffer pleinement soufflé car je veux la latence la plus faible possible. PCAP est beaucoup trop lent dans ce cas.
Vous devez extraire des informations sur les paquets TCP du cadre IP de Ethernet.
que veux-tu faire? Veuillez décrire plus sur votre caprice, si vous avez besoin d'un serveur TCP pour gérer les paquets TCP et leur réponse, vous avez besoin d'expériences dans Win32, C ++, composants MFC et COM. Mais une autre solution simple existe: Win32 Tun / Tap
Je tiens à minimiser le nombre de dispositions «logiques» à l'intérieur du socket wrapper. Et si c'est un caprice pour vous, je pense que vous ne devriez pas répondre à cette question. ta
La question ressemble à vous essayer de mettre en œuvre ECHO TCP? Quel serait mal avec une prise TCP unie et simplement envoyer la charge utile immédiatement à l'autre point final?
Qu'est-ce qui vous a enquêté?
En outre, vous réalisez que la manipulation TCP est souvent faite dans le matériel de toute façon? L'utilisation de la mise en œuvre de TCP intégrée est susceptible d'être la chose la plus rapide que vous puissiez faire, car il s'agit simplement d'une enveloppe autour des bibliothèques natives Win32 en premier lieu. Je ne comprends pas ce qui pourrait éventuellement être aussi sensible à la latence qu'il est correct d'utiliser C # mais pas d'accord pour utiliser les capacités de prise TCP intégrées. Essayez-vous d'optimiser clairement le cycle de la CPU? Si c'est le cas, ne faites pas cela en C #.
C'est echo. Je vais comparer des prises brutes et logiques de toute façon. et publier les résultats. Mais je m'attends à ce que RAW soit peu de NS plus rapide (difficile à mesurer sur Windows, mais je vais essayer) ... Je sais que C ++ sur l'HR serait plus rapide mais qui est en dehors de la portée de ce projet
@Default Bien que cela semble simple soit nécessaire une attention particulière. Je vais mettre en œuvre les deux - Prise brute et logique et voir la différence. Dans environ 2 semaines, le serveur dans les questions est encore en transit.
ECHO est également intégré à Windows, si tout ce dont vous avez besoin est ECHO.