C/C++ Server und Client Rolle auf dem gleichen Device für N Verbindungen

[Andre (Gast)]

Hallo,

ich bin gerade an den Anfängen der Netzwerk-Programmierung.

Ein paar Worte zur Plattform:
Ich benutze einen Zynq zc706 Board und als OS das mitgelieferte 
Freertos.
Das Freertos verwendet die LWIP Komponente für die Netzwerkkommunikation

Nach was ich suche ist ein Konzept in dem ein Server gleichzeitig auch 
als Client agiert um N Devices miteinander zu verbinden.

Jetzt kann ich mir selbst etwas ausdenken und zwei Thread erzeugen wobei 
ein Thread als Server und der zweite Thread die Aufgaben des Clients 
übernimmt.
Für die Verbindung des Servers würde ich einen Socket öffnen, um die 
Request zu beantworten. Und einen zweiten Socket um Anfragen über den 
Client Thread zu verschicken.

Ich denke das ist ein typischer User-Case, zu dem es sicher schon 
Strategien entwickelt wurden:
Hat jemand dazu einen Vorschlag.

Danke

[Noch einer (Gast)]

Mit dem lwip_select() kannst du es einfach wie in den prähistorischen 
Berkeley-Programmen machen.

Nur ein Thread.

Dieser Thread wartet, bis sich auf irgend einem Socket etwas tut.

Meldet sich ein Client an, macht es den Datensocket auf.

Kann von einem Socket gelesen werden, legt es die herein kommenden Daten 
in eine Warteschlange ab.

Kann auf einen Socket geschrieben werden, schaut es nach, ob noch was in 
der dazugehörenden Warteschlange liegt.

Stehen noch andere Arbeiten an, ruft es select() mit einem Timeout von 0 
auf.

[Ing (Gast)]

Andre schrieb:
> Hallo,
>
> ich bin gerade an den Anfängen der Netzwerk-Programmierung.
>
> Jetzt kann ich mir selbst etwas ausdenken und zwei Thread erzeugen wobei
> ein Thread als Server und der zweite Thread die Aufgaben des Clients
> übernimmt.
> Für die Verbindung des Servers würde ich einen Socket öffnen, um die
> Request zu beantworten. Und einen zweiten Socket um Anfragen über den
> Client Thread zu verschicken.
>
> Ich denke das ist ein typischer User-Case, zu dem es sicher schon
> Strategien entwickelt wurden:
> Hat jemand dazu einen Vorschlag.
>
> Danke

Ich war vor derselben Problematik gestanden und hatte es wie folgt 
gelöst:
Der Server bestand bei mir aus zwei Threads. Ein Thread hat 
kontinuierlich auf neue Verbindungen gelauscht und der zweite hat vom 
dem Socket der bestehenden Verbindungen kontinuierlich gelesen. Somit 
habe ich das lauschen auf neue Verbindungen vom Lesen der Socketdaten 
entkoppelt.
Für den Client hatte ich keinen eigenen Thread spendiert. Kann man aber 
machen.

Hast du dir schon über Error Handling Gedanken gemacht? Kannst du zB 
schon detektieren was passiert wenn der Client Socket geschlossen wird 
oder der Client abgeschossen wird, ohne das der Socket vorher sauber 
geschlossen wird?Soll das ganze dann Reconnect fähig sein?

[(prx) A. K. (prx)]

Falls hier implizit TCP gemeint sein sollte, einen etwas allgemeineren 
Einwand aus der Praxis:

Man sollte sich im Vorfeld darüber klar werden, ob komplexe und 
dynamische TCP-Konstrukte vieler Nodes mit Zwischenschaltung eines 
Servers als Verbindungsagenten wirklich sinnvoll sind. Da in einer 
solchen Konstruktion sowohl im Socket-System als auch im Agenten 
Zustände doppelt gepflegt werden, kann es stabiler sein, das 
Socket-System davon zu entlasten und das ganze auf UDP aufzusetzen.

Analog dazu ist auch zu bedenken, ob wirklich virtuelle Drähte zwischen 
den Nodes benötigt werden, oder ob Messaging nicht auch ausreicht. 
Besonders wenn die Netzverbindungen eher instabil sind und die 
Zeitbedingungen von der Anwendung definiert sind. Dann kann es schnell 
passieren, dass das eigenständige Zeitverhalten des Socket-Layers nicht 
hilft, sondern nur stört.