Indy TCP Server nur max ~100mal instanziierbar ?

[DataCool]

@Dax: Dummheit ? :mrgreen:

[Ultimator]

Zitat:

Ich schiesse mich an: was soll das ganze?

Aua!

[supermuckl]

lol cool data gibts auch hier und nicht nur auf der enterprise *freu*

also..

1. an den threads selbst kanns wohl net liegen da ich nen delphi thread ( TThread ) z.b. 1000 mal zugleich instanziieren kann
ohne ein bisschen viel speicher zu verbrauchen !

2. nein kein portscanner..

3. nein ich will auch net nur paar ports haben ich will alle ;)

also um es kurz zu sagen ( sonst wird man ja nur immer belehrt wieso man so blöd ist und nich nur 10 ports benutzt.. )

man startet dieses programm auf einem pc wo hinter nem router mit NAT steht
das prog macht ( bestenfalls ) auf allen freien ports einen server socket auf und listet auf ankommende connections
wenn ich nun mit einem portscanner auf den router ( die internet anbindung ) checken würde und gleichzeitig irgendwie die messages von meinem programm abfangen könnte wo mir sagen auf welchem port ich durch NAT reingekommen bin dann weis ich welche ports geforwardet sind ;) ganz einfach !

ok man kann das auch klein bisschen anderst machen das der server nur 100 ports öffnet.. dann wieder 100 andere usw
aber mal die grundsätzliche frage.. wo hängts bei dem scheiss teil ? die threads könnens nich sein das könnt ihr mir nich erzählen.. ich kann tausende threads aufmachen und z.b. in jedem thread wiederum n TidICMP instanziieren und nen multithreaded pinger bauen !
also wieso zum geier hat der kack so eine beschränkung drinne o_O *nixblick*

:cheers:

[DataCool]

Hi supermuckl,

ich denke schon das Dein Problem an den Threads liegt, denn
jeder IdTCPServer ist dafür designd um Multi-Threaded viele Connections zu behandeln,
d.h. das jede Serverinstanz ein gewissenheit Overhead benötigt;
z.B. ist eine der privaten Variablen des IdTCPServers
FThreads: TThreadList;
ist und wenn Du den Constructor von TThreadList etwas näher anschaust wirst Du feststellen, das
jede ThreadList widerrum
FLock: TRTLCriticalSection;
verwendet.

Darum ist klar das Du 1000 TThread Instanzen nicht mit 1000 TIdTCPServer Instanzen vergleichen kannst, weil zusätzlich noch jeweils 1000 CriticalSections erzeugt werden; denn restlichen Overhead nicht mit betrachtet.

Natürlich kannst Du auch 1000 TidICMP Instanzen erzeugen, weil da nicht der Overhead zur Threadverwaltung benötigt wird.

Die Lösung deines Problems hast Du selber schon genannt:
Einfach weniger Instanzen erzeugen und nach und nach alle Ports durchgehen.

Zitat:

also wieso zum geier hat der kack so eine beschränkung drinne o_O *nixblick*

Die Leute von "nevrona" haben ganz umsonst die Komponenten entwickelt, wie würdest Du das finden, wenn du Dich jahrelang um die Entwicklung und Pflege eines Produktes kümmerst und damit eine der besten "Internet-Komponenten-Sammlung" geschaffen hast und
dann kommt jemand des Weges der die Arbeit als selbstverständlich hinnimmt und sie auch noch beschimpft ?

[supermuckl]

nimm mal nich so wörtlich :)

@Dax: Dummheit ? <- *übersehenhab* :/

und unterstell mir mal net das ich die arbeit net würdige von nevrona

ich weis das die indy komponenten die besten sind keine frage :)

mir is klar das ein tidtcpserver mehrere threads verwalten kann usw.. aber das das dann gleich bei 123 instanzen ein limit haben muss is ja schon hart.. wenn ich da an den rest denke wo ich schon gemacht hab da is das *flach gesehen* n klacks ?!

ok dann muss ich mal schauen ob ich was mit sockets erreichen kann ( mit einem thread je server oder komplett selbst gemacht )
da dürfte dann nichmehr soviel overhead drin stecken ^^

und wenn alle stricke reissen mach ich das mit wechselnden ports ( unschön aber tut )

wüsste jemand auf die schnelle was da am besten wäre als tcp server ?
da gibts ja die fastnet teile von D6.. dann hab ich da noch die ICS componenten... dann noch die indy sockets..

jemand erfahrung was da am geeignetsten wäre ?

:coder: