nicht angemeldet
Unix-Domain-Sockets
Hallo,
habe noch keine Antwort auf meine Frage erhalten und die letzte Nachricht ist bereits nicht mehr im Forum sichtbar. Deshalb erlaube ich kurz erneut zu fragen. Vielleicht findet sich ja doch noch jemand, der mir helfen könnte.
ich habe eine Verständnisfrage zu Unix-Domain-Sockets:
Wenn ich ein Unix-Domain-Socket anlege und einen Server habe, der das Socket ausliest. Ebenfalls gibt es mehrere Clients die auf das Socket schreiben, die der Server abarbeitet und die Antwort auf das Socket schreibt. Kriegt dann immer der Client seine Antwort oder ist das "Prozess-Unabhängig"?
Also z.B.:
Client A schreibt auf Socket
Client B schreibt auf Socket
Server arbeitet Request von Client A ab
Client B liest von Socket
Hat dann Client B die Antwort auf den Request von Client A? (was natürlich nicht erwünscht wäre; falls doch: wie kann ich das umgehen?)
Bei TCP-Verbindungen ist es eigentlich klar: der richtige Client kriegt die Antwort. Wie wäre es, wenn ich statt Unix-Domain-Sockets UDP-Sockets verwenden würde (da heisst es ja: schreiben an IP:Port, bzw. lesen von bestimmter IP:Port)?
Irgendwie schnall ich das noch net so ganz...
Grüsse,
Maxwell
-
Hallo Maxwell (nochmal ;-) ),
ich habe eine Verständnisfrage zu Unix-Domain-Sockets:
Wikipedia: http://en.wikipedia.org/wiki/Sockets. Oder sowas.
Wenn ich ein Unix-Domain-Socket anlege und einen Server habe, der das Socket ausliest. Ebenfalls gibt es mehrere Clients die auf das Socket schreiben, die der Server abarbeitet und die Antwort auf das Socket schreibt. Kriegt dann immer der Client seine Antwort oder ist das "Prozess-Unabhängig"?
Also z.B.:
Client A schreibt auf Socket
Client B schreibt auf Socket
Server arbeitet Request von Client A ab
Client B liest von Socket
Hat dann Client B die Antwort auf den Request von Client A? (was natürlich nicht erwünscht wäre; falls doch: wie kann ich das umgehen?)meines Wissens hast du das ganze falsch verstanden. Ein Socket ist immer nur eine bidirektionale multiplexfähige Verbindung. Auf deutsch heißen diese 2 Worte: Eine Verbindung zwischen zwei (mehr oder weniger) gleichberechtigten Partnern, wo jeder gleichzeitig lesen und schreiben kann.
In der Realität läuft das üblicherweise so ab: Dein (paralleler, d.h. mehrere Anfragne gleichzeitig beantwortender) Server lauscht an dem Socket. Client A verbindet sich damit. Server forkt (spaltet sich in einen neuen Prozess/Thread) und verbindet sich mit A. Der Hauptprozess/Thread lauscht weiterhin am Socket, während Thread A des Servers mit Client A ungestört reden kann. Anschließend kann sich B auf die gleiche Weise verbinden.
Bei TCP-Verbindungen ist es eigentlich klar: der richtige Client kriegt die Antwort. Wie wäre es, wenn ich statt Unix-Domain-Sockets UDP-Sockets verwenden würde (da heisst es ja: schreiben an IP:Port, bzw. lesen von bestimmter IP:Port)?
Ich gebe zu, ich habe bis jetzt auch nur TCP- und UDP-Sockets (mit C, Perl, PHP, Java) programmiert und keine Unix-Domain-Sockets, aber meines Wissens sind letztere quasi das gleiche Prinzip wie TCP-Sockets, nur eben auf lokaler Ebene, ohne Netzwerk. In jedem Fall ist es so, wie du sagst: Der richtige Client kriegt die Antwort. Denn man kommuniziert stets nur mit einem Client gleichzeitig.
Anders is es mit UDP-Sockets, wie du sagst. Es ist verbindungslos, d.h. es existiert nie eine Verbindung. Du lauscht einfach an einem UDP-Port, und es kommt keine Anfrage, auf Verbindnug, auf die dein Programm forken könnte, sondern es kommt ein Datagramm, sprich ein Datenpaket, was du verarbeiten kannst. Darin enthalten ist der Absender - dem kannst du antworten oder auch nicht. Keine mehreren Threads/Prozesse und trotzdem ein paralleler Server, d.h. ein Server, der mit mehreren Clients gleichzeitig reden kann. Wie das organisiert ist, ist dann seine Sache (er kann ja "die Clients" in irgendwelchen Arrays speichern oder so ähnlich)
Viele Grüße,
Sven