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.

[negaH]

Guckst du hier :) http://www.delphipraxis.net/viewtopi...r=asc&start=15

Auf Win2k Rechnern können bis zu 2004 Threads per Prozess laufen. Im obigen Posting habe ich mal meine Quick&Dirty Lösung gepostet. Im Gegensatz zu deiner Lösung, die ja den zu scannenden Port Bereich im vorhinein auf die max. Anzahl an Threads verteilt, scannt meine Lösung sequentiell den Bereich mithilfe der Threads. Werden z.b. 1024 Threads erzeugt so scannen diese erstmal alle Ports von 1-1025. Sollte ein Thread fertig sein nimmt er den nächsthöheren Port. Man kann als max. Threadanzahl ohne Probleme einen Wert festlegen, zB. 10000, ohne das es Probleme mit der verfügbaren Anzahl an Threads pro Prozess gibt.
Sollte diese Anzahl erreicht sein so wird das OS bei CreateThread() mit einem Fehler zurückkehren. D.h. die Threaderzeugungs-Loop geht von 0-10000 aber bei 2004 Threads macht das OS dicht. Da aber die Threadfunktion linear scannt ist dies kein Problem.
Mit deinem Chunkweisen Vorgehen ist dieser Trick nicht möglich ohne das Portbereiche nicht gescannt werden.

Das Problem mit der Listbox lässt sich ganz einfach lössen. Mich interessieren nur erreichbare Ports (was soll ich mit den Ports die geschlossen sind in der Anzeige??) Es wäre also sinnvoll in der ListBox nur die geöffneten Ports anzuzeigen. Meistens sind das ca. 14-20 Ports aus einem Bereich von 65534 möglichen.

Übrigens: der Unterschied beim scannen von 65534 Ports besteht darin das mit 256 Threads 270 Sekunden zu 80 Sekunden bei 1024 Threads benötigt werden.

Gruß Hagen

[Assarbad]

Da ich inzwischen den Algo umgestellt habe (vorher waren die threads nicht komplett autark), sollte meine Lösung auch mit 1024 threads laufen *grins* ... aber ich hatte damit zuvor halt Probleme, weshalb ich die Anzahl begrenzt habe.

Daß es auf NT begrenzt ist, war mir bekannt, aber wußte nicht mehr die genaue Grenze - Danke ;)

Das mit der Listbox hat im DF schon einer vorgeschlagen, kommt also :mrgreen:

Das mit chunkweise ... ist es doch eingentlich garnicht, oder haben wir nur andere Begrifflichkeiten? Denn eigentlich werden bei mir jetzt auch zuerst die ersten Ports gescannt. Vorher hatte ich dran gedacht einen Bereich an jeden Thread zu übergeben. Aber am wichtigsten sind meistens Ports 0..1023 ;)

[negaH]

Ich habe nur kurz in den Source reingeschaut, Asche auf mein Haupt.
Deine Methode mit dem Counter + I als Index für den Thread erzeugt einen falschen Eindruck und ich musste sie nochmals analysieren. Irgendwas kam mir faul dran vor.

Also wir erzeugen 4 Threads nacheinander und IP.NumThreads = 4.

Code:

ThreadIndex = I    Portnummern im Thread 

              0  =     1   5    9
              1  =     2   5   10
              2  =     3   7   11
          ------------------------
              3  =     4   8   12

In obiger Tabelle mal diese Threads 0 bis 3 mit Index I. Daneben die Portnummern die jeder Thread scannt.
Nun erzeugst du in der Schleife von 0 bis IP.NumThreads -1 deine Threads, aber beim Thread 3 meckert das OS und dieser Thread wird NICHT erzeugt. Damit entstehen Lücken im gescannten Portbereich.

In meinem Source bin ich anders vorgegangen. Globale Variablen CurrentPort und MaxPort. CurrentPort wird auf den ersten zu scannenden Port gesetzt, MaxPort auf den höchsten zu scannenden Port. Nun werden die x Threads erzeugt und jeder Thread arbeitet in einer Schleife. Der Thread holt mit ScanPort := InterlockedExchangeAdd(CurrentPort, 1) seinen nächsten Port ab und erhöht gleichzeitig threadsafe CurrentPort um +1. Sollte ScanPort >= MaxPort sein so terminiert der Thread.
Durch diese Vorgehensweise ist garantiert das wenn 10000 Threads erzeugt werden sollen aber nur 5 tatsächlich beginnen zu laufen, keine Lücken entstehen. 2. kann man anhand von CurrentPort erkennen was der höchste gerade gescannte Port ist. 3. kann man MaxPort noch nachträglich reduzieren. Die Threads die schneller connecten holen sich öfters den nächsten Port.
Werden also 4 Threads erzeugt und CurrentPort ist 1, dann würden diese 4 Threads sich ihren Port holen und CurrentPort wäre 5. Nun connectet der Thread 2 mit ScanPort = 3 schneller als alle anderen, dann würde er mit Port 5 weitermachen und CurrentPort wäre 6. Usw. usw. d.h. je nach Geschwindigkeit beim connecten holen sich die Threads die Ports ab.


Gruß Hagen

[negaH]

Das Problem ist hier:

Delphi-Quellcode:

    while (IP.StartPort + i + Counter) <= IP.EndPort do
    begin
// Scan ports ...
      inc(Counter, IP.Numthreads); <----
    end;

IP.NumThreads ist 4, aber nur 3 Threads laufen tatsächlich.
Damit entstehen Lücken im Portbereich.

Gruß Hagen

[negaH]

Achso eines habe ich vergessen. Wenn man so viele Threads nacheinander erzeugt dann beginnt ein Teil der Threads schon zu arbeiten und ein anderer Teil muß erst warten bis er überhaupt startet. Ist eigentlich logisch. Das OS kann nicht erst 1024 Thread erzeugen und dann alle in einem Rutsch starten. Anscheinend startet es immer ruckweise einen Block von wartenden Threads. Dies hat aber Konsequenzen für uns. Wir können nämlich nicht sagen ob das OS diese wartenden Thread gemäß ihrer Erstellungsreihenfolge startet. Da in deinem Source über Index I und Counter + IP.NumThreads jedem Thread ein fester Portbereich zugeordnet wurde, kann es durchaus vorkommen das bestimmte Portbereiche ungleichmäßig und zeitversetzt gescannt werden.

Du solltest den Port nicht vom Thread abhänig machen. Jeder Thread holt sich wenn er bereit ist sequentiell den nächsten zu scannenden Port. Eben so wie in meinem Source :)

Gruß Hagen

[Assarbad]

Hi Hagen,

auch wenns simple Mathematik ist, schau lieber nochmal auf den Code mit der WHILE-Schleife ;) Ich sehe da keine Lücken ... eher Überschneidungen, sobald ich IP.Numthreads-1 nehme ;)

Außerdem sollte ich vielleicht klarstellen, daß es hier eher darum ging ein Programm zu schreiben, welches mal die Grenzen bei Threads austestet. Es ging mir keinesfalls darum einen perfekten Portscanner abzuliefern. Aber es ging mir durchaus darum einen Scanner abzuliefern, der schneller ist als der Durchschnitt (daher so viele Threads) ... außerdem wollte ich eben einige Sachen, wie Parameterübergabe bei Threads etc pp austesten.

Also Kleinigkeiten werd' ich mglw noch beheben, aber ansonsten steht der Source zur Verfügung, jeder der will kann ihn selbst modifizieren ;)

Übr.: Du hast natürlich recht, daß es schneller ginge, wenn sich immer sofort der nächste freie Thread den nächsten Port grabscht .... ich werd's mir mal anschauen. Wichtiger ist mir erstmal was anderes ;)

Danke fürs Feedback anyway.

[negaH]

Zitat:

Ich sehe da keine Lücken

Also entweder schnalle ich da was nicht oder ich kann dein Source nicht lesen. Hier noch mal die Tabelle aber erweitert:

Code:

ThreadIndex = I    Portnummern im Thread 

              0  =     1   7   13 
              1  =     2   8   14 
              2  =     3   9   15 
          ------------------------ 
              3  =     4  10   16 
              4  =     5  11   17
              5  =     6  12   18

Man will vom Port 1 bis 18 scannen und möchte dazu 6 Threads benutzen.
In deiner Loop mit CreateThread() gehst du von I := 0 to IP.NumThreads -1, wobei IP.NumThreads := 6 ist. Um mit diesen 6 Threads bis Port 18 zu scannen muß jeder Thread 3 mal pingen. So wie oben in der Tabelle dargestellt. Nun kann das OS nur 3 = DREI Threads erstellen, d.h. deine CreateThread() Schleife erzeugt Thread Nummer 0,1,2 schlägt aber fehl bei Thread Nummer 3,4,5. Deine while Schleife im Thread Code sieht so aus.

Delphi-Quellcode:

    while (IP.StartPort + i + Counter) <= IP.EndPort do
    begin
// Scan ports ...
      if ScanTCPPort(IP.IP, IP.StartPort + i + Counter, TCPsock) then
        PostMessage(hDlg, WM_ADDIP_TCPCONNPORT, IP.IP, IP.StartPort + i + Counter)
      else
        PostMessage(hDlg, WM_ADDIP_TCPPORT, IP.IP, IP.StartPort + i + Counter);

// Increase by number of threads
      inc(Counter, IP.Numthreads);
    end;

Damit würde Thread 0 bei Port 19 terminieren, Thread 1 bei Port 20 und Thread 2 bei Port 21. Die Ports 4,5,6,10,11,12,16,17,18 würden aber nicht gescannt da Thread 3,4,5 überhaupt nicht durch das OS erzeugt wurden.

So das nenne ich Lücken.

Wenn ich dennoch falsch liege dann kläre mich bitte auf, denn durch deinen Kommentar habe ich das Gefühl bekommmen das ich da was nicht schnalle.

Gruß Hagen

[Assarbad]

Sorry, mir ist das zu hoch, ich verstehe einfach deine Beispiele nicht. Also bei mir gibts im Praxistest keine Probleme :-/

Und rein logisch sollte es auch funzen ...

Thread 0 scannt zuerst Port 0 und geht dann zu 0+IP.Numthreads ... also exakt einen Port weiter als der letzte andere Thread.

Aber ich werd trotzdem mal schauen, ob ich das mit deiner Logik implementieren kann. Ist mir einfach zu affig fremden Code zu nehmen ... ich machs lieber selber ;)

[negaH]

Delphi-Quellcode:

type
  PIP = ^TIP;
  TIP = record
    IP,StartPort,EndPort: DWORD;
    NumThreads: DWORD;
  end;

var
  IP: TIP;

function ScanThread(I: DWORD): DWORD; stdcall;
var
  Counter: DWORD; // Local remainder
begin
  Result := 0;
  Counter := 0;
  while (IP.StartPort + I + Counter) <= IP.EndPort do
  begin
    Write( IP.StartPort + I + Counter, ', ' );

    Inc(Counter, IP.Numthreads);
  end;
end;

procedure Test;
var
  I: Integer;
begin
  IP.NumThreads := 6;
  IP.StartPort := 1;
  IP.EndPort := 18;
  for I := 0 to IP.NumThreads -1 do
    if I > 3 then Break
      else ScanThread(I);
end;

In obigem Code simmuliere ich mal deinen Algo. Aber so als ob 6 Threads laufen sollten aber nur 3 Threads durch's Operation System erzeugt wurden. D.h. die Schleife mit der Erzeugung der Threads erzeugt nur Threads 0,1,2 und Threads 3,4,5 werden durch's OS nicht erzeugt.

Die Threadfunction ScanThread() wird direkt aufgrufen, statt wie bei Threads im eigenen Context.

Das WriteLn sollte alle Ports von 1 bis 18 ausgeben, ich erhalte aber nur (1, 7, 13) + (2, 8, 14) + (3, 9, 15) + (4, 10, 16). Also genau wie ich es gesagt habe.

Wird also NumThreads = 2048 angegeben und das OS lässt aber nur 128 Threads zu, dann bleiben Lücken.


Und hier meine Lösung:

Delphi-Quellcode:

type
  PIP = ^TIP;
  TIP = record
    IP,StartPort,EndPort: DWORD;
    NumThreads: DWORD;
  end;

var
  IP: TIP;

function ScanThread(I: DWORD): DWORD; stdcall;
var
  Port: Integer;
begin
  Result := 0;
  repeat
    Port := InterlockedExchangeAdd(@IP.StartPort, 1);
    if Port > IP.EndPort then Break;
    Write( Port, ', ' );
  until False;
end;

procedure Test;
var
  I: Integer;
begin
  IP.NumThreads := 6;
  IP.StartPort := 1;
  IP.EndPort := 18;
  for I := 0 to IP.NumThreads -1 do
    if I > 3 then Break
      else ScanThread(I);
end;

Ausgabe:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,

Der Schönheitsfehler dabei ist nur das ScanThread() hier nicht als separater Thread parallel ausgeführt wird. Aber das Prinzip bleibt gleich.

Übrigens, wenn du globale Variablen unschön findest, warum ist IP: TIP auch global ??


Gruß Hagen

[Assarbad]

Mir ist bewußt, was du meinst, aber ich verstehe noch immer nicht, wie du mit meinem Code Probleme hast? Bei mir tauchen die derzeit einfach nicht auf. Außerdem ist das minimale Verhältnis von Ports zu Threads Ports/NumThreads.
Einzig, deine Scheduling-Logik kann auch verschmerzen, wenn keine Threads mehr erstellt werden konnten. Das bietet meiner nicht. Also warts mal ab, bis ich mir selber was mit Hilfe deiner Hinweise ausgedacht hab ;)

Daß IP global ist, hat den Grund, daß ich sonst Numthreads mal Speicher allozieren müsste um ihn an den einzelnen Thread zu übergeben. Ist auch ne Variante und hat sicher auch seine Vorteile, aber naja :)

[negaH]

Nee ich habe keine Probleme mit deinem Code und wollte eigentlich nur auf eine kleine "Schwachstelle" hinweisen. Normalerweise wende ich bei meinem Portscanner den Trick an so viele Threads wie möglich zu erzeugen. Es zeigte sich das auch unter Win2k die Anzahl der Threads pro Prozess unterschiedlich sein kann. Manchmal bekomme ich 2004 oder auch nur 129 Threads zum laufen. Deshalb dachte ich das es wichtig wäre darauf hinzuweisen das wenn man versucht z.b. 256 Threads zu erzeugen, eben dies fehlschlagen kann. Durch die Logik deines Algos. könnten dadurch Lücken entstehen. Aber was soll's, es ist dein Source und du must wissen wie es richtig für dich ist. Ich wollte eigentlich nur nett zu dir sein, heul :(

Gruß Hagen

[Assarbad]

Danke Hagen ;)

Keine Angst, mir ist inzwischen bewußt, worauf du hinaus willst. Vorher dachte ich, du meintest einen Fehler im Code (den ich partout nicht gesehen hab) ... inzwischen weiß ich, du meinst einen Fehler in der "Logik". Und das werde ich natürlich ausbügeln ;)

Also keinen Grund zu verzweifeln. Mir war bloß weiter oben nicht klar, worauf du hinaus willst ;)

[Assarbad]

@Hagen: InterLockedExchangeAdd() gibts auf 9x nicht (lt. PSDK). Nimm einfach XADD. In der BASM-Newsgroup haben sie gemeint JEDE CPU-Operation ist atomic!

Hier nun die geupdatete Version. Downloadlink siehe oben. ;)

[Assarbad]

Kleines Update. Es sind jetzt mind. 110 kB Daten dazugekommen!
Dafür zeigt der Scanner jetzt die Kurznamen der Ports an.

Bitte keine Vorschläge für ne extra Datei mit den Portbeschreibungen! Kenn ich, mag ich nicht.

Downloadlinks bleiben wie gehabt.

[negaH]

Zitat:

@Hagen: InterLockedExchangeAdd() gibts auf 9x nicht (lt. PSDK).
Nimm einfach XADD. In der BASM-Newsgroup haben sie gemeint JEDE CPU-Operation ist atomic!

Jop, das ist richtig bezogen auf Single Processor Systemen. Ich will auch garnicht darüber diskutieren denn die Konstrukteure der CPU's müssen sich was beim LOCK Prefix gedacht haben. Da es mir aber zu mühsig ist das alles exakt zu ermitteln nehme ich XADD das einen implizites LOCK Prefix hat.

Zitat:

Bitte keine Vorschläge für ne extra Datei mit den Portbeschreibungen! Kenn ich, mag ich nicht.

Schade eigentlich, da ich gerade heute ermittelt habe was auf Port 4662, 4242 und 1126 los ist und wer mich da permanent mit geblockten Packets überflutet. Echte Kotzsoftware dies.

Die Beschreibungen der Ports wäre dann erweiterbar und durch verstänliche Zusatzinfo ergänzbar. Zb. Port 135 ist auf Windowssystemen der böse DCOM Port. Die IANA Definitionen interessieren in weiten Teilen keinen so richtig und schon garnicht MS.

Gruß Hagen

[negaH]

Zitat:

gemeint JEDE CPU-Operation ist atomic!

Sorry sehe jetzt erst das "JEDE", was natürlich nicht besonders für das Wissen der BASM Leute spricht. Natürlich kann garnicht jede COPU Operation atomic sein. Z.b. ENTER,LEAVE,SYSENTER,CPUID sind extrem aufwenige und hochkomlexe Operationenm, die können garnicht atomic sein.
Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic. Dazu muß nmlich der 4 byte Wert auch an einer 4 Bytes Adresse stehen. Sollte dies nicht der Fall sein so ist dies nicht mehr Atomic und somit nicht mehr Threadsafe.

Gruß Hagen

[Assarbad]

Okay ... überzeugt. Ich werde es als Option mit einbauen ;)

Kann aber noch etwas dauern. Sitze grade wieder an etwas anderem.

[Assarbad]

Zitat:

Zitat von Hagen

Natürlich kann garnicht jede CPU Operation atomic sein.

Falsch, sie muß es sogar sein! Du kannst die auf dem Level der Maschinensprache nicht weiter aufspalten! 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))!

Zitat:

Zitat von Hagen

Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic.

Sorry, sehe ich nicht so! EAX ist 4 Byte breit, also werden 4 Byte von dieser Adresse gelesen, komme was da wolle! Das hat was mit der Breite der Operanden zu tun. Der Assembler wird sich zB weigern sowas zu machen:

Code:

mov EAX, BYTE PTR [Adresse]
mov EAX, WORD PTR [Adresse]

Und dies aus gutem Grunde. Sollte ich was übersehen haben, kannst du gern nochmal ins Detail geben.

Hier noch die Unterstützung meiner Argumentation:

Code:

88 / r    MOV r/m8,r8       Move r8 to r/m8
89 / r    MOV r/m16,r16       Move r16 to r/m16
89 / r    MOV r/m32,r32       Move r32 to r/m32
8A / r    MOV r8,r/m8       Move r/m8 to r8
8B / r    MOV r16,r/m16       Move r/m16 to r16
8B / r    MOV r32,r/m32       Move r/m32 to r32
8C / r    MOV r/m16,Sreg**    Move segment register to r/m16
8E / r    MOV Sreg,r/m16**    Move r/m16 to segment register
A0    MOV AL, moffs8*    Move byte at ( seg:offset) to AL
A1    MOV AX, moffs16*    Move word at ( seg:offset) to AX
A1    MOV EAX, moffs32*    Move doubleword at ( seg:offset) to EAX
A2    MOV moffs8*,AL       Move AL to ( seg:offset)
A3    MOV moffs16*,AX    Move AX to ( seg:offset)
A3    MOV moffs32*,EAX    Move EAX to ( seg:offset)
B0+ rb    MOV r8,imm8       Move imm8 to r8
B8+ rw   MOV r16,imm16       Move imm16 to r16
B8+ rd    MOV r32,imm32       Move imm32 to r32
C6 / 0    MOV r/m8,imm8       Move imm8 to r/m8
C7 / 0    MOV r/m16,imm16    Move imm16 to r/m16
C7 / 0    MOV r/m32,imm32    Move imm32 to r/m32

Verschiedene Operandenbreiten und -Kombinationen führen zu verschiedenen Opcodes.

(1): Hyperthreading schaltet nur unabhängige Befehle parallel ... und beim Itanium das Ausführen aufs Gratewohl (also sozusagen nach vorbeugend) ändert auch an oben geschildertem nix!

[negaH]

Jey, jay ich wusste es, wir beginnen uns zu streiten !

Zitat:

Natürlich kann garnicht jede CPU Operation atomic sein.

Zitat:

Falsch, sie muß es sogar sein! Du kannst die auf dem Level der Maschinensprache nicht weiter aufspalten! 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))!

Eben nicht. Komplexe Befehle beeinflussen durch den Microcode interne Statusregister und externe Addressleitung sequentiuell. D.h. innerhalb mehrer Taktzyklen ändern sich Register und Addressleitungen. Die Maschinensprache ist somit irrelevant und der Microcode ist das Argument das eine CPU eben nur sehr wenige atomare Operationen beherrscht. Betrachtet man dies unter dem Gesichtspunkt der Multiprozessorenfähigkeiten das kann es auch nicht mehr Threadsafe sein. 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.

Zitat:

Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic.

Zitat:

Sorry, sehe ich nicht so! EAX ist 4 Byte breit, also werden 4 Byte von dieser Adresse gelesen, komme was da wolle! Das hat was mit der Breite der Operanden zu tun. Der Assembler wird sich zB weigern sowas zu machen:

Auch hier stimmt deine Annahme nicht. Wird über MOV EAX,[Address] auf Speicher zugegriffen der nicht an 4 Byte Grenzen ausgerichtet ist so entstehen durch Cachemisses zusätzliche Micro Ops. Diese wiederrum führen dazu das der Cache eventuell reorganisiert wird und da der cache eine shared Resource in einer Multiprocessor plattform ist würde das ohne LOCK zu Problemen führen.

Sogesehn sind deine Argumente genau die nötigen Argumente um meine Argumentation zu unternaumern :)

ABER! bevor es mit unserer Diskussion weitergeht müssen wir klären was Multithreading des Operationssystemes ist und was Multiprocessing auf Mehrprocessorensystemen bedeutet. Das eine hat mit dem anderen NICHTS zu tun solange das Threading auf Single Prozessoren Systemen läuft.
Nur auf Single Prozessoren wäre deine Annahme richtig, da dort keine andere CPU konkurrent zu aktuellen CPU an den Addressleitungen rumpfuscht. Denn dann kann innerhalb eines externen OpCodes der durch den MicroCode ausgeführt wird kein Taskswitch durchgeführt werden. Somit kann auf einem Single Prozessoren System die eine CPU nicht zur gleichen Zeit auf die gleiche Adresse zugreifen so daß es zu einer NICHT-atomaren Operation käme. D.h. eine CPU = ein Atom = alle Operationen atomar. Dies betrachtet aber nur die CPU und nicht die CPU einer Grafikkarte, nicht einen DMA Chip oder nicth einen IDE Controller, die alle ebenfalls in den Speicher reinschreiben können. So, wird ein OpCode wie MOV EAX,[Address] durch den CPU MicroCode in mehrere Zugriffsoperationen zerlegt, da die Adresse nicht an 4 Bytes ausgerichtet wurde, dann heist das das diese 4 Bytes durch 2 gesplittete Leseoperation gelesen werden müssen. Genau dazwischen kann aber die Grafikkarte, der DMA Chip oder der IDE Controller den noch fehlenden Speicherbereich aktualisieren. Die CPU würde im nächsten Zyklus somit in EAX einen falschen Wert zusammenbauen. Deshalb kann eine Single CPU eben nicht atomar sein.

Da ich aber NICHT der absolute Experte auf diesem Gebiet bin, interessiert mich dieser Fakt nicht. Ich gehe deterministisch vor und nehme an das das LOCK Prefix für Multiprozessoren wichtig ist, und auf Single Prozessoren kann es nicht schaden.


Gruß Hagen

[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* :mrgreen:

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