Berkeley Sockets: Hinweise

 [Vorheriges Kapitel]  [Vorherige Seite]  [Inhaltsverzeichnis]  [Nächste Seite]  [Nächstes Kapitel]

*Typischerweise wird (wie in dem vorangegangenen Beispiel) der Typ SOCK_STREAM bevorzugt. Zwar gibt es auch einige auf SOCK_DGRAM basierende Protokolle -- jedoch hat die dadurch gewonnene Effizienz ihren Preis in dem zusätzlich erforderlichen Verwaltungsaufwand wegen der Unzuverlässigkeit.
 
*Im Gegensatz zu SOCK_SEQPACKET kommen bei SOCK_STREAM einzelne Pakete (also das, was mit einer write- oder read-Operation geschrieben bzw. gelesen wird) nicht in ihrer originalen Form an -- die Implementierung ist frei, sie beliebig zu zerstückeln und zusammenzusetzen. Das erfordert auf der einlesenden Seite eine geschickte Pufferung.
 
*Wer fleißiger schreibt als der andere lesen kann (das kann auch an der Netzverbindung liegen), wird genauso schlafen gelegt wie eine Partei, die etwas lesen möchte, ohne daß im Augenblick etwas da ist.
 
*Wenn beide Parteien gleichzeitig lesen (oder genügend viel schreiben) gibt es dementsprechend einen Deadlock. Dies muß durch ein geeignetes Protokoll vermieden werden.
 
*Mit select (oder poll) ist es möglich, festzustellen, welche Verbindungen lese- oder schreibbereit sind. Außerdem gibt es einen nicht-blockierenden Modus, bei dem ein Prozeß dann einen Fehler zurückerhält, wenn er andernfalls blockiert worden wäre.
 

 [Vorheriges Kapitel]  [Vorherige Seite]  [Inhaltsverzeichnis]  [Nächste Seite]  [Nächstes Kapitel]
Copyright © 1996 - 2003 Andreas Borchert, in HTML konvertiert am 01.10.2003