Community  »  Perl: Allgemeines Forum

Sockets "optimieren"	Seitenanfang
Hallo Gemeinschaft! :) Ich habe da ein kleines/großes Problem. Für einen Sicherheitstest von "außen" will ich eine Art Portscan verschiedener TCP-Ports durchführen. Dafür will ich einfach einen Socket nehmen, und den testen: $sock = = new IO::Socket::INET ( PeerAddr => $victim, PeerPort => $port, Proto => 'tcp', Type => SOCK_STREAM); Ist sicher geläufig die Methode. Jetzt zum eigentlichen Problem. Ich hab ganz einfach mal einen Performanztest auf Linux und Windows durchgeführt. Ergebnis: auf dem Linux benötigt der Test aller 65536 Ports ca. 58 Sekunden. Angenehm. Unter Windows (XP) benötigt das gleiche Programm für nur 100 Ports (1-100) jedoch ungefähr 100 Sekunden. Die Frage ist also: was verursacht diesen riesigen Verlust (~1200fache Aufwandssteigerung)? Liegt es irgendwie daran, dass unter Windows irgendeine Umsetzung von AF_INET auf irgendeinen WinSocket oder sowas stattfindet? Was könnte man tun, um die Performanz unter Windows an die von Linux anzugleichen? Threads bringen ja nur bis zu einem gewissen Grad was. Wenn ich nun alle Ports teste, bin ich bei 64 Threads immer noch bei ca. 15 Minuten unter Windows. Hmmm... Grüße, BigM Datum: 14.02.2007-09:48
re: Sockets "optimieren"	Seitenanfang
Bin mir jetzt ziemlich sicher, dass es am "Nagle-Algorithmus" in Windows liegt. Wie kann man den austricksen? Setzt man beim new-Konstruktor das Attribut Blocking=>0, ist der zurückgelieferte Wert immer undefined, auch wenn eine Verbindung stattfinden müsste (das sagt zumindest die Methode ohne Blocking). BigM Datum: 14.02.2007-15:53
re: Sockets "optimieren"	Seitenanfang
http://support.microsoft.com/kb/138831/de Datum: 15.02.2007-02:03
re: Sockets "optimieren"	Seitenanfang
Schön und gut, aber der Link hilft mir nicht wirklich weiter. Auf meinem Host läuft kein SNA-Server. Das Programm ist ja kein Server, sondern ein Client. Dumm ist halt die Geschichte, dass bei der Option "Blocking=>0" immer undefined zurückgeliefert wird, auch wenn wie zB. bei Port 80 eine Verbindung stattfinden müsste, aber daher kein Rückschluss auf die Verbindung mehr möglich ist. Warum eigentlich? TCP_NODELAY hinterher mit sockopt setzen ist grundsätzlich für mein Problem Quatsch, denn die Konstruktion des Socket-Objekts dauert ja allein dadurch schon so lang. Kann man irgendwo in Windows direkt diesen Nagle-Algorithmus ausschalten? Das Ding muss doch auszutricksen sein! :) Datum: 16.02.2007-09:39