Kleiner und schneller Portscanner (nonVCL) mit EXE!

[Assarbad]

So, hier die Version 1.00.

Der hauptsächliche Vorteil liegt in der Benutzung vieler Threads.

Als Download ACE, RAR, ZIP

Es sollten insgesamt weniger Probleme (auch auf Windows 9x) auftreten. Source ist dabei.

[Assarbad]

Das denke ich nicht

komplett korrigiert
der Microcode ist nur dann relevant, wenn es mehrere CPUs gibt, ansonsten geht es garnicht anders, als daß jeder Opcode (entsprechend einem Mnemonic) atomar ist. Ausnahmen könnten die SIMD-Opcodes sein. Zu denen informiere ich mich nochmal. Daß LOCK natürlich bei Single-CPU nicht stört ist ja klar

Soweit ich mich entsinne muß eine GPU immer noch einen Interrupt auslösen! Das geht nur zwischen Opcodes, womit das ganze atomar bleibt.
Das gleiche gilt für andere externe Ressourcen auf einer Single-CPU!

[Assarbad]

Kleiner Chat zwischen mir und "jemandem der sich damit auskennt". Er meint wir diskutieren aneinander vorbei. Ich meine er hat recht, hier ein Vermittlungsversuch:

Code:

[00:16] Xandros: was der hagen sagt stimmt - hat aber keine konsequenzen wenn man unter nem os programmiert
[00:16] Xandros: also klar zerlegt die cpu den opcode in microcode
[00:16] -=Assarbad=-: das wollte ich ausdrücken mit dem unterschied zwischen Opcode und Microcode
[00:16] -=Assarbad=-: aber das ist irrelevant
[00:16] Xandros: und wenn man mehrere cpus hat - machen die das natürlich parallel für jeden ihrer eigenen opcodes
[00:17] -=Assarbad=-: was er meint, ist aber das es bei mehreren CPUs konflikte geben kann. IMO aber nicht bei SMP (hieß das nicht Synced MP???)
[00:18] Xandros: wenn nun zufällig eine cpu das datum im speicher ändert - was aber eine andere CPU gerade bearbeitet, kommt es zur kollision und der algo der dann anspringt ist von dem hersteller der cpu abhängig - weil der speicher muss mit dem cache der cpus wieder kohärent gehalten werden - das protokoll heißt MESI was da hauptsächlich genutzt wird
[00:19] Xandros: SMP = Shared multi prozessing
mehrere cpus auf einem speicher, aber mit eigenem cache und MESI als protokoll um den speicher und die caches aller CPUs in Sync zu halten
[00:19] -=Assarbad=-: ups sorry ;)
[00:19] -=Assarbad=-: also ist es doch gesynced?
[00:20] Xandros: und ich glaub er meint die konflikte, die durch MESI halt gelöst werden müssen
[00:20] Xandros: diese konflikte sind ja der grund, weshalb mein system nicht 4 mal schneller wird, wenn ich 4 cpus reinpacke
[00:20] -=Assarbad=-: dann wäre es also weiterhin atomar, selbst bei SMP, oder?
[00:21] -=Assarbad=-: du meinst also wir reden auf verschiedenen ebenen, hagen und ich???
[00:22] -=Assarbad=-: Das wollte ich aber durch folgenden Satz ausschließen: "Wie komplex der darunterliegende Microcode ist, ist komplett irrelevant (, denn in der CPU wird jeder Opcode quasi wie eine Funktion behandelt ... bevor diese nicht zurückkehrt, gehts auch nicht weiter (1))!"
[00:22] Xandros: es muss immer konsistent gehalten werden - folgendes szenario:
cpu1 holt adresse für datum zum schreiben asu speicher in den cache
cpu2 holt sich dasselbe datum ...
problem, cpu2 muss nun erfahren, wenn cpu1 das datum updatet
.. aber das machen die cpus alle selbst - deswegen sind die teile auch so teuer
[00:22] Xandros: ja - genau, verschiedene ebenen - das was hagen sagt hat null relevanz für programmierer
[00:23] -=Assarbad=-: kann ich den Chat zitieren?
[00:24] -=Assarbad=-: darf ich?
[00:24] Xandros: naja, wenn du meinst das ich euch beide richtig verstanden hab und nun nicht auch völlig vorbeidiskutiert habe - klar
[00:25] -=Assarbad=-: jut ich probiers mal ;)
[00:25] Xandros: ich hab nur den eindruck das die ganze diskussion nicht besonders sinnvoll ist, wenn ich ehrlich bin
[00:26] Xandros: weil I/O opereationen über ein medium sich nun mal nicht besonders guten threaden lassen - weil das medium gibts halt nur einmal genauso, wie threads in smp systemen außer einem kleineren overhead im vergleich zu ganzen prozessen auch keinen speedup bringen
[00:27] Xandros: ähh ich meine single cpu systemen
[00:27] Xandros: nicht SMP
[00:27] Xandros: im letzten satz
[00:30] Xandros: an der stelle: 
"Bei solchen Konstellationen wird durch das LOCK Prefix alle parallelen CPU's angewiesen zu schlafen, damit eben der EINE OpCode der intern aus vielen sequentiellen OpCodes im MicroCode ausgeführt wird nicht dazu fürht das sich z.b. Überschneidungen auf den Adressleitungen zum Speicher auftreten."
[00:31] -=Assarbad=-: ???
[00:31] Xandros: bin ich mir nicht sicher - es gibt diese locking tatsächlich, aber nicht aus dem grund den er hier nennt - wie gesagt, darum kümmern sich die cpus selber

[negaH]

Jay, zwei Leute zwei Meinungen Ich müsste mich auch erst wieder tiefer einarbeiten, aber meine obigen "Weisheiten" stammen aus einer Intel Docu zum Multiprocessing auf'm P3.

Letztendlich ging's ja um unsere PortScanner und deren Methoden ihre Daten zu synchronisieren. Hier ist es nur wichtig auf Nummer sicher zu gehen ohne übertriebenen Aufwand zu betreiben. So gesehen habe ich mich in meiner Source auf eine sichere Methode gestützt, egal welche Aussage über atomare Operationen richtig oder falsch ist.

Viel interessanter wäre es nun den PortScanner zu beschleunigen und einen IP Bereich einzubauen. Oder aber die gefundenen Ports anzusprechen um herauszubekommen was hinter dem Port für Software wartet

Mich würde auch brennend interessieren wie der PortScanner meinen Rechner so scannt als wenn der Scanner aus dem WEB versucht meinen Rechner zu scannen. Z.b. hat meine FireWall alles geblockt, dennoch findet mein PortScanner die geblockten Ports.

Gruß Hagen

[negaH]

Hey, das ist ja unfair ! Du hast ja Berater an deiner Seite die dazu noch extreme Experten sind. Wie soll ich da noch gewinnen können

Gruß Hagen

[Assarbad]

Hehe ... darum gings ja nicht. Es ging nur darum unsere Diskussion auf eine Ebene zu bringen. Kannst es als eine Art Schiedsmann ansehen. Wenn du seine UIN willst, dann verbinde dich mal mit mir: 28 16 45 und ich schick dir seine UIN

[negaH]

Und schon wieder erwischt, mir bleibt heute aber auch nichts erspart. Erst komme ich mit meinem shit Primzahl Problem nicht vorwärts, dann erfahre ich das FreeLancer in Zukunft auch Gewerbesteuer zahlen müssen, danach offenbart mir meine Krankenversicherung das ich meinen Zahnersatz doch selber zahlen muß, und nun....
macht mir Asserbad ein Anbot seine UIN mir mitzuteilen !
und ich muss gezwungenermaßen zugeben das ich nicht weiß was das ist. Ich nehme mal an es ist ICQ, und ich habe das noch nie gemacht. Sorry, ich weiß noch nichtmal was für Software ich brauche

Gruß Hagen

[Assarbad]

Hagen Hagen ... *kopschüttel-mit-grinsen*

Es handelt sich um ICQ, korrekt

Download in verschiedenen Sprachen: http://www.icq.com/download/
JAVA-Version vom Browser aus: http://go.icq.com/

Ich benutze Trillian: http://www.trillian.cc/ (der beherrscht mehrere Protokolle und ich hab die Pro gekauft.)

[Assarbad]

Sorry Hagen, ich geh erstmal schlafen

Kannst dir ja mal ne UIN besorgen, Xandros ist meist online - ich geb dir dann seine UIN.

[Ronaldo]

Hallo,

ich versuche seit Tagen einen SQLServer im Netz zu finden. Das stellt mich leider vor ein großes Problem. Wie es aussieht, gibt es kein funktionierende Möglichkeit dafür, oder keiner weiß wie. Durch einen Menge Foren lesen bin ich auf den Postscanner gestoßen. Könnte man sowas nicht einfach umbauen um alle SQLServer im Netz zu finden. Mit dem Tool finde ich ihn, aber gut ich keine seine IP. Falls es nicht so ist, wollte ich ganz gerne alle die in meinem IP Kreis sind auflisten. Den Port kenn ich auch (1433). Leider verstehe ich den Quelltext so gut wie gar nicht.

Es wäre nett wenn mir da jemand helfen könnte.

Gruß

Ronald

[negaH]

Du musst den Portscanner umbauen. Statt auf einer IP alle Ports zu scannen, muß man in einem IP Bereich nur jeweils einen Port scannen. Dies dürfte mit Asserbad's Source kein problem sein.

Gruß Hagen