Diskussion:Socket (Software)

message: "Sockets bilden eine Schnittstelle (API) zwischen der TCP/IP-Implementierung und der eigentlichen Applikationssoftware. " Das ist so nicht ganz richtig. Ein Socket muß nicht auf TCP/IP aufsetzen. Denkbar wäre auch UDP/IP!
Setzuna 
:Der Meinung bin ich auch ... ich behaupte sogar das es nicht nur dafür verwendet wird, sondern auch für Bluetooth etc. - stimmt das ?
:
::Bei Bluetooth bin ich mir nich sicher, aber die Socket API ist eine Abstraktion für alle Arten von Netzwerkkommunikationen, dazu sollte, glaube ich, auch Bluetooth gehören. Sockets sind nicht IP Protokoll spezifisch, sondern können auch über IPX, Appletalk, und alle anderen Netzwerkprotokolle kommunizieren.
::
:::Hab's korrigiert... wie der Artikel ja auch ausfuehrt kann ein Socket fuer alle moeglichen Arten von Protokollen verwendet werden (POSIX definiert meines Wissens nach Sockets fuer Unix Domain Sockets, TCP/IP und UDP/IP, alles andere ist optional).
:::DarkDust 23:24, 27. Aug 2005 (CEST)

message: Meines Wissens nach ist die Winsock API nicht einfach nur der BSD Socket API nachempfunden, sie stammt sogar direkt aus FreeBSD, spricht Microsoft hat Netzwerk-Code wie die Socket-API aus FreeBSD uebernommen (was die BSD Lizenz ja ausdruecklich erlaubt). Weiss da jemand mehr dazu ? --DarkDust 10:24, 15. Nov 2005 (CET)
thread_title:  Geschichte 

message: Ich würde gern wissen wie groß der eigene Kummunikationsspeicher von Sockets ist, oder wie groß er werden kann (maximalgröße).
-- Skia 14:50, 30. Nov. 2006 (CET)
replies: text: Wozu sollte einen das interessieren ? Ich wuesste nicht dass man abfragen kann (nochmal: wozu auch ?). --DarkDust 16:22, 30. Nov. 2006 (CET)

text: Neee, sowas wird nicht ausgelagert, sondern der "send" wird blockieren solange der Puffer voll ist (es sei denn O_NONBLOCK ist gesetzt, dann kommt er mit laut man page mit EAGAIN oder EWOULDBLOCK zurueck). --DarkDust 17:27, 30. Nov. 2006 (CET)
replies: text:  Bei Datagramm-Sockets (z.B. UDP) wird "send" nicht blockieren, sondern die Packete kommen dann einfach nicht an. Die Idee, dass "Packete" erst in einen "großen Speicher" zwischen den beiden Kommunikationspartnern kommen würden, ist bei Sockets falsch. Je nach Sockettyp (verbindungslos/orientiert/...) blockiert "send" (genauso wie "write" blockiert, wenn die Festplatte noch nicht bereit zum Schreiben ist) oder sendet einfach munter weiter, ohne dass die Packete ankommen. Mit Auslagerungsdateien, etc. hat das gar nichts  zu tun. --Benji 01:38, 21. Okt. 2007 (CEST)
thread_title:  Speicher 

message: Es gibt den Begriff auch bei Prozessoren, v.a. bzgl. der Größe der Größe eines Prozessors. Sollte dies nicht ebenfalls erwähnt werden? --NDBro 15:37, 7. Mär. 2008 (CET)
replies: text: Ich habe einen entsprechenden Hinweis eingebaut. --j ?! 15:50, 7. Mär. 2008 (CET)
thread_title:  Prozessoren 

message: Aus dem Artikel geht nicht hervor, dass ein Socket eigentlich ein Speicherbereich ist, der sowohl Konfigurationsparameter, als auch einen Buffer für ein- und ausgehende Daten hat. Er ist eine Ressource, die einem Prozess eindeutig zugeordnet wird. 
Weiters ist das Java-Beispiel zwar nett, jedoch unvollständig. Entweder man lagert es aus als komplettes Beispiel (Client und Server, am besten inklusive einem Ablaufdiagramm), oder man löscht es. Ebenso interessant wäre dann auch ein Beispiel in C, C#, ...
Bei "Geschichte" etwas unverständlich: Das 3-Way-Handshake des TCP-Protokolls, welches hier für den Verbindungsaufbau und Verbindungsabbau verwendet wird, ist nicht erwähnt. Und außerdem benötigt man bei Sockets nicht zwingend einen Verbindungsaufbau und -abbau! Bsp.: UDP hat keinen Verbindungsaufbau. Siehe Drei-Wege-Handshake, UDP -- Alexander P. 21:48, 29. Mai 2008 (CEST)
replies: text: Ich habe nun versucht, dem Artikel insgesamt eine bessere Form zu geben und inhaltlich und stilistische Ungenauigkeiten zu verbessern. Die erwähnten Lücken bestehen aber weiter. -- Dk 14:24, 22. Sep. 2009 (CEST)
thread_title:  Überarbeiten 

message: Der Text und das C-Beispiel sind gnadenlos veraltet und sollten nur noch als historisch eingestuft werden.
Im Jahr 2013 ist eine Socket-Beschreibung mit AF_INET anstelle von AF_INET6 verantwortungslos, zumal AF_INET6 trotz noch geringer Verbreitung von IPv6 (ISPs, Netzwerke) in nahezu fast allen aktuellen Anwendungen verwendet wird.
Bei JAVA und auch Haskell wird das Problem bereits weiter unten gelöst  - es sind schließlich etwas höhere Programmiersprachen.
--Tschäfer (Diskussion) 23:10, 30. Mär. 2013 (CET)
thread_title:  IPv6 

message: Bin gerade selbst dabei Sockets in Python zu benutzen und ohne vorherige Erfahrung in dem Bereich können sich tückische Fehler einnisten.
So kann der socket.recv() Funktion eine Puffergröße als Argument übergeben werden - es wird aber nicht garantiert, dass Länge der Rückgabe = Puffergröße.
Wie ist das bei Java, insbesondere in dem Java Beispiel ? Garantiert InputStream, dass bei input.read(data) der übegebene Puffer data auch voll gefüllt wird ? 
Auf das Thema Blockierungen sollte noch in dem Artikel eingegangen werden. --Webskipper (Diskussion) 15:07, 6. Jun. 2013 (CEST)
thread_title:  recv() / read(), blocking und non-blocking Verhalten 

message: Wenn ich das richtig sehe, ist der Baustein seit Mai 2008 drin. Der Artikel hat sich seitdem stark geändert und ich sehe nicht, dass der Artikel zurzeit dringend einer Überarbeitung bedarf. Würde den Baustein deshalb gerne entfernen. Was meint ihr? --Noresoft (Diskussion) 18:42, 3. Nov. 2016 (CET)
replies: text: Hab ihn dann mal entfernt. --Noresoft (Diskussion) 15:40, 26. Nov. 2016 (CET)
thread_title:  Baustein "überarbeiten" noch aktuell?