Server als Client nutzen

[pinkysbrain]

Hallo,

ich soll eine Applikation schreiben, die auf mehreren Rechnern läuft.
Dabei sollen alle Rechner gleichzeitig als Server bzw Client funktionieren können.
Die Rechner verbinden sich, wählen einen Master und schicken dann alle Anfragen an diesen.
Die Kommunikation soll über xml rpc funktionieren.

Ist es grundsätzlich möglich einen Server zu starten, der wiederum als Client gegenüber anderen Servern auftritt?
Oder muss ich auf jedem Rechner einen Client und einen Server starten um das ganze zu realisieren? Falls ja, wie läuft dann die lokale Kommunikation zwischen Client und Server ab?

Das Minimalbeispiel wären zwei Rechner die jeweils die Adresse des anderen kennen. Beide Rechner sollen sich über einen XML RPC Aufruf verbinden können. Danach wird einer der beiden als Master ausgewählt und erhält alle nachfolgenden Anfragen beider Rechner.
Wie kann so etwas grundsätzlich mit Java und XML RPC realisiert werden?

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt.
Vielen Dank für die Hilfe.

 

[InfectedBytes]

Wenn du UDP nutzt, dann gibt es quasi keine server. Jeder kann beliebig Nachrichten empfangen und verschicken, also peer to peer mäßig. In deiner Anwendung kannst du dann damit einen Server wählen lassen und anschließend nur noch nachrichten an diesen schicken.

Mit TCP geht es natürlich auch, allerdings muss dann jeder eine Listener erzeugen und mehrere Clients, welche sich mit den anderen verbinden, etc.

Für so eine peer-to-peer mäßige Anwendung würde ich UDP bevorzugen, allerdings musst du beachten, dass UDP nicht garantiert das die verschiedenen Nachrichten auch in der gesendeten Reihenfolge ankommen, oder ob sie überhaupt ankommen.

 

[Dukel]

Wenn du UDP nutzt, dann gibt es quasi keine server. Jeder kann beliebig Nachrichten empfangen und verschicken, also peer to peer mäßig. In deiner Anwendung kannst du dann damit einen Server wählen lassen und anschließend nur noch nachrichten an diesen schicken.

Natürlich gibt es auch mit UDP einen Server. Ohne Server kann man zwar Pakete verschicken, aber die werden dann von niemand angenommen.

 

[InfectedBytes]

nein, udp ist ein verbindungsloses protokoll. Man sendet und empfängt direkt die Pakete.
Und da jeder sender/empfänger gleich ist, gibt es auch keine client-server architektur, denn jeder kann nach belieben an jeden senden und von jedem empfangen.

Auf Anwendungsschicht kann man wenn man möchte natürlich eine client-server architektur einbauen, aber auf Protokollebene gibt es keine Server als solches.

 

[Dukel]

Verbindungslos hat nichts mit Client / Server zu tun. Sonst gäbe es keinen DNS Server, welcher auf UDP/53 lauscht.
Versuche dir selbst einmal Pakete per UDP an einen beliebigen Port zu schicken, auf dem kein Server lauscht.
Verbindungslos heisst nur, dass es keine Flusskontrolle gibt und ggf. Pakete unterwegs verloren gehen.

 

[InfectedBytes]

ok, dann formuliere ich es halt anders: bei udp sind server und client dasselbe.

 

[Dukel]

Nein! Das ist Blödsinn.
Ein Server ist ein Programm, welches auf einem festgelegten Port lauscht und Pakete (egal ob TCP oder UDP!) annimmt und verarbeitet.
Ein Client ist ein Programm, welches auf einem fast beliebigen Port Pakete (egal ob TCP oder UDP!) an ein Server schickt.

 

[InfectedBytes]

nein, das abwarten auf Pakete hat nichts mit Server zu tun. Auch ein client ist in der Lage Pakete zu empfangen.
Wie z.B. bei TCP, dort muss allerdings der Client eine Verbindung zum Server aufbauen und kann erst danach nach belieben Daten senden und empfangen.

Ich glaube wir reden ein wenig aneinander vorbei.

Ein Client ist ein Programm, welches auf einem fast beliebigen Port Pakete (egal ob TCP oder UDP!) an ein Server schickt.

Das würde ich eben nicht so sehen, denn ein Client schickt nicht nur Daten, sondern empfängt sie ggf. auch. Natürlich kannst du auch sagen das der Client eben auch einen Server beinhaltet, welcher für den Empfang zuständig ist. Aber dann muss man im Falle von TCP halt auch sagen, dass die Server-Seite eben einen Server beinhaltet, welcher die Verbindung annimmt und dann für jede neue Verbindung einen weiteren Server öffnet, welcher die Daten vom jeweiligen Client annimmt.

Die Sache mit dem Senden/Empfangen würde ich halt eher als eine Eigenschaft des Sockets betrachten, ob er eben Daten sendet oder auch empfängt.
Bei TCP betrachte ich daher dann nur den Socket als Server, welcher sich um die Verbindungsanfragen kümmert. Danach wird durch accept jeweils ein neuer Socket erstellt, welcher für das senden/empfangen von Daten zuständig ist. Dieser socket ist dann gleichwertig mit dem socket auf der seite des Client. Beide können sich gegenseitig Daten senden und eben jene auch vom anderen empfangen.

Bei UDP ist man direkt an dem Punkt, an dem ein Socket nach belieben senden und empfangen kann.
Dementsprechend würde ich hier nur vom Server reden, wenn die Anwendungslogik eben sowas wie einen "Dienst" bereitstellt, welcher vom Client genutzt werden kann.

 

[Dukel]

Ok War etwas undeutlich beschrieben.
Mir geht es um den Verbindungsaufbau. Wenn einmal eine Verbindung besteht kann natürlich der Server auch antworten.
Aber das ist bei UDP und TCP gleich!

Du brauchst aber sowohl bei TCP als auch bei UDP einen Server. Verschicke doch mal ein UDP Paket an einen Rechner auf dem kein Service läuft. Wer soll das Paket dann annehmen und verarbeiten?