Netzwerkprogramm, wie aufbauen?

[Markus]

Hallo,

ich möchte ein Programm schreiben, dass folgendes kann: ich habe 4 PCs (PC1, PC2, PC3, PC4).

Auf PC1 soll ich gleichzeitig etwas an alle anderen PCs schicken können. Diese sollen das automatische empfangen und reagieren (z.B. etwas zu PC1 zurückschicken).

Wie soll ich das Strukturieren? Müssen alle PCs server UND client sein? Soll ich die Sockets oder die Indys nehmen?

[Sebastian R.]

Ja, du schreibst sozusagen nur ein Programm, was du dann auf alle 4 PCs draufmachst. Das enthält dann einen Server zum empfangen und einen Client zum Versenden!

[Markus]

Und wie soll ichs mit dem senden, bzw mit dem Verbinden am besten machen, also eine permanente Verbindung oder immer unmittelbar vor dem Senden verbinden und dann wieder trennen?

[supermuckl]

verbunden bleiben
mit tcp/ip
die clients verbinden sich alle mit dem multithreaded tcp server
nach aufbauen der verbindung kann in beide richtungen kommuniziert werden
client seitig für den empfang muss ein selbst erstellter thread herhalten der in einer endlosschleife readln macht
und der server hat ein ereignis fürs empfangen (on execute) und fürs senden einfach in einer schleife alle connecteten clients durchgehen und writeln machen

das war speudocode *g*

[Markus]

Wenn ich mit den Sockets arbeite, TServerSocket hat doch ein Ereignis beim Empfangen, oder?

Jetzt muss ich nur noch rausfinden, wie man einen multithreaded Server erstellt

[Der_Unwissende]

Hi,
ich würde mal sagen, eine permanente Verbindung macht (insbesondere bei TCP/IP) wenig Sinn. An sich sollte man möglichst Ereignisorientiert arbeiten. Bei zustandslosen Protokollen kann es schwer werden eine Verbindung permanent zu halten (geht einfach gar nicht). Natürlich kannst du beliebig lange readln machen, aber es macht (imho) wenig Sinn. Damit wird ein solcher Rechner immens viel Zeit (alles was frei ist) damit verbringen auf eine Nachricht zu warten. Da du eher nicht mit ein paar Mhz neue Nachrichten verschickst (geschweige denn mit ein paar GHz), verschwendest du damit eigentlich nur Ressourcen.

Natürlich muss jeder Server (auch Serversocket) auf eine Anfrage reagieren können, in Delphi gibt es dieses Ereignis für dich schon gekapselt. Wenn du nun ein Programm schreibst, dass als Server dient, der die Rundnachrichten verschickt, kannst du natürlich einfach an alle eingetragenen Empfänger etwas verschicken. Das heißt, ein Server kann sowohl empfangen als auch verschicken. Bietet sich doch irgendwie an, den auch gleich für die "Clients" zu benutzen. Wenn du auch dort Server verwendest, kannst du also leicht auf Nachrichten vom eigentlichen Server reagieren und diesem auch Antworten und das ganze ohne jegliche Art von polling (schont die CPU immens).
Natürlich kann man auch in eine gewissen Interval pollen (mittels Readln), aber dann ist dann die Intervalgrenze eine Schwierigkeit. Wartest du zu lange, so wirst erst verzögert auf ein Ereignis reagieren, ist das Interval zu kurz, kommt es sehr häufig zu unnötigen Aufrufen, optimal ist es natürlich einfach auf ein Ereignis zu reagieren.

Was Threading angeht, da hat Luckie ein Tutorial für.

Gruß Der Unwissende

[supermuckl]

da ich mein denken auf den indy tcp server/client bezogen hatte, muss ich hier mal diese aussagen ein wenig in frage stellen:

Zitat:

Hi,
ich würde mal sagen, eine permanente Verbindung macht (insbesondere bei TCP/IP) wenig Sinn.
-> grund? ich denke das ist falsch. jede tcp app versucht, die verbindung so lang wie möglich dauerhaft zu halten

An sich sollte man möglichst Ereignisorientiert arbeiten.
-> richtig

Bei zustandslosen Protokollen kann es schwer werden eine Verbindung permanent zu halten (geht einfach gar nicht)
-> seit wann ist tcp zustandslos? es gibt nicht umsonst diverse timeouts und fehlerkorrekturen im protocol


. Natürlich kannst du beliebig lange readln machen, aber es macht (imho) wenig Sinn.
-> auf clientseite kannste das mit den indys garnicht anderst machen, wenn du auf messages reagieren willst, die vom server kommen, die du aber nicht voraus sehen kannst (anderst wäre es, wenn du eine anfrage an den server schickst und der dir EINE antwort gibt. aber dieser fall ist ja in dieser konstellation nicht vorraus zu sehen )

Damit wird ein solcher Rechner immens viel Zeit (alles was frei ist) damit verbringen auf eine Nachricht zu warten. Da du eher nicht mit ein paar Mhz neue Nachrichten verschickst (geschweige denn mit ein paar GHz), verschwendest du damit eigentlich nur Ressourcen.
-> ganz falsch. bei den indys wartet readln solange bis das timeout einsetzt an dieser codestelle OHNE ressourcen zu verbrauchen. in einer endlosschleife würde das super hinhauen.

Natürlich muss jeder Server (auch Serversocket) auf eine Anfrage reagieren können, in Delphi gibt es dieses Ereignis für dich schon gekapselt.
-> on execute bei den indys
-> readln bei dem client (wahlweise in einer endlos schleife in einem thread)

Wenn du nun ein Programm schreibst, dass als Server dient, der die Rundnachrichten verschickt, kannst du natürlich einfach an alle eingetragenen Empfänger etwas verschicken. Das heißt, ein Server kann sowohl empfangen als auch verschicken. Bietet sich doch irgendwie an, den auch gleich für die "Clients" zu benutzen. Wenn du auch dort Server verwendest, kannst du also leicht auf Nachrichten vom eigentlichen Server reagieren und diesem auch Antworten und das ganze ohne jegliche Art von polling (schont die CPU immens).
-> das verstehe ich jetzt nicht, wie du mit einem server auf einen server connecten willst o_O

Natürlich kann man auch in eine gewissen Interval pollen (mittels Readln), aber dann ist dann die Intervalgrenze eine Schwierigkeit. Wartest du zu lange, so wirst erst verzögert auf ein Ereignis reagieren, ist das Interval zu kurz, kommt es sehr häufig zu unnötigen Aufrufen, optimal ist es natürlich einfach auf ein Ereignis zu reagieren.
-> endlosschleife mit readln ohne verzögerungszeiten = optimal falls nicht ein application layer protocol verwendet wird

Was Threading angeht, da hat Luckie ein Tutorial für.
-> alles was im onExecute vom Server ausgeführt wird, ist schon in einem thread von den indys
d.h. man muss serverseitig nicht einen einzigen thread erstellen - das ist schon in den indys aktiv
man muss allerdings aufpassen und threadsafe in den ereignissen programmieren.

clientseitig bräuchstest evtl maximal einen thread, der die nachrichten vom server empfängt.
ich empfehle die indy demos zu studieren (tcpserver/client) da ist alles was ich gelabert habe als code einzusehen!

[Markus]

So, hab mich jetzt mal intensiver damit beschäftigt. Schreibe das ganze nun in C#, aber das spielt keine Rolle (der Aufbau bleibt der selbe).

Bis jetzt bin ich so weit:

Server-Programm:
Nach dem Start wird ein Thread gestartet, der auf anfragende Clients jeweils einen neuen Thread erstellt, welcher die Verbindung mit einem Client verwaltet (für jeden Client einen extra Thread).

Client-Programm:
Das Abrufen einer ankommenden Message wird mittels eines Threads, der in einer Schleife den Buffer ausliest, realisiert.

Das Senden vom Server zum Client klappt somit auch schon, aber ich hab noch Probleme:
1. Die PCs werden alle gleichzeitig eingeschaltet, d.h. es kann sein, dass dass die Clients VOR dem Server da sind. Was soll ich dann machen?
2. Wie soll ich den "Rückweg" realisieren. Meine Idee war, dass wenn ein Client auf dem Server "geadded" wird, dass dann der Client seinerseits einen Server startet und der Server ne Anfrage an den Client schickt.

Aber das Hauptproblem ist Nr. 1, weiß nicht so recht wie ich das machen soll, wenn die Clients zuerst da sind...

[supermuckl]

zu 1:
du versuchst zu connecten
-> schlägt fehl -> timer für reconnect starten, der alle 10 sec neu probiert zu connecten
-> ist connected -> timer anhalten falls gestartet

zu 2:
genau so wie der hinweg
sobald eine tcp verbindung aufgebaut ist kannst du mit den vorhandenen instanzen der clients und server IN BEIDE RICHTUNGEN kommunizieren

da brauchst du nicht unnötiger weise im client nochmal einen server instanziieren oderso.