Diskussion:Socket

"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 (falsch signierter Beitrag von Setzuna (Diskussion | Beiträge) 15:15, 9. Jun. 2005‎ (CEST))

Der Meinung bin ich auch ... ich behaupte sogar das es nicht nur dafür verwendet wird, sondern auch für Bluetooth etc. - stimmt das ?

(nicht signierter Beitrag von 145.253.162.202 (Diskussion) 16:01, 20. Jul. 2005‎ (CEST))

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.

(nicht signierter Beitrag von 80.144.161.59 (Diskussion) 13:34, 11. Aug. 2005‎ (CEST))

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)

Geschichte

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)

Zitat: "Der Kommunikationsablauf heutiger Netzwerkapplikationen, beispielsweise von Client-Server-Anwendungen folgt einem einfachen Konzept:

1. Verbindungsaufbau

2. Datenaustausch

3. Verbindungsabbau"

Das ist blanker Unsinn und eine Kategorienverletzung: Hier ist das Thema, ob Protokolle verbindungsorientiert sind oder nicht. Es gibt sehr wohl heutige Anwendungen, die nicht verbindungsorientiert operieren.

(nicht signierter Beitrag von 134.225.15.150 (Diskussion) 22:20, 28. Feb. 2007‎ (CET))

Programmierbeispiel für Java

Ich bin nicht ganz glücklich mit der zunehmenden Java-»Beispielisierung« in der Wikipedia. Soll heißen: In zahlreichen Artikeln findet man immer wieder interessante Hinweise, wie man das in Java programmieren kann. Auch wenn Java so wahnsinnig plattformunabhängig ist und dieses Konzept sicher zur Perfektion und gewisser "Bekanntschaft" getrieben hat, finde ich es trotzdem etwas übertrieben, die Sprache *so* in den Vordergrund zu stellen. Socket-Programmierung beispielsweise ist so "nativ", dass vermutlich sogar ein in C geschriebener Beispielsourcecode für Windows und Linux so gut wie identisch wäre (nur so eine Behauptung). Wobei die Programmiersprache C sogar hier sehr viel mehr Relevanz aufweist als Java, da ja bekanntlich das Socket-Konzept von Unix kommt und ursprünglich in C geschrieben war (klar).

Grüße,
--Benji 23:44, 2. Mär 2006 (CET)

Naja du kannst ja wenn du magst Beispiele in anderen sprachen einfügen. Und wenn ich mich recht erinnere gibt es auf Windows nur bedingte Unterstützung für den Unix Befehl select, der sehr häufig bei sockets angewandt wird. (nicht signierter Beitrag von 80.141.116.28 (Diskussion) 21:35, 6. Feb. 2008‎ (CET))

Meiner Meinung nach ist das Beispiel in Java nicht wirklich vorteilhaft. Interessant wäre hier mehr die Definition des Types "Socket" und "ServerSocket". 2 Objekte, ein Array und ein Integer + die Methoden des Objekts sagen nichts über einen Socket aus. Ein reines C Beispiel bringt da schon mehr. Das Beispiel in Java ist zwar eine nette Information wenn man mal schnell eine Applikation schreiben will, die Sockets benötigt, aber sagt nichts über ein Socket selber aus. Ein C Beispiel zeigt ebenfalls, dass ein Socket (wie alles andere auch unter Unix) nur eine Datei ist. Wie das unter Windows aussieht, ist mir jetzt nicht bekannt. Aber ich glaube, wenn ein WinSocket wirklich nur eine implementierung von den FreeBSD Sockets ist, sollten da kaum Unterschiede sein.

MfG Pennywise1911 (23:41, 9. Mai 2011 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Geschlecht?

Was für ein Geschlecht hat denn ein Socket? Der Duden hat das Wort nicht, im Artikel steht es auch nicht. 217.80.94.37 15:06, 3. Mär 2006 (CET)

In der mir bekannten Literatur wird folgendes verwendet: das Socket, die Sockets. --Matzedi 22:30, 14. Apr 2006 (CEST)

Danke schön! 217.80.101.91 15:25, 15. Mai 2006 (CEST)

Ich denke eher: der Socket, die Sockets,

im Bezug auf der Sockel, die Sockel.

(nicht signierter Beitrag von FrozenIceMan (Diskussion | Beiträge) 12:56, 7. Jul 2009 (CEST))

Speicher

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)

Wozu sollte einen das interessieren ? Ich wuesste nicht dass man abfragen kann (nochmal: wozu auch ?). --DarkDust 16:22, 30. Nov. 2006 (CET)

Die Frage ist nicht wozu einen das interessieren sollte, sondern wenn schon was es bringen würde das zu wissen. Mich hats einfach nur interessiert wie groß das ganze werden kann, da es ja auslagerungsdateien sind. --Skia 16:46, 30. Nov. 2006 (CET)

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)

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)

Prozessoren

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)

Ich habe einen entsprechenden Hinweis eingebaut. --j ?! 15:50, 7. Mär. 2008 (CET)

Überarbeiten

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)

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)

Haskell???

Also ich haette es nuetzlicher gefunden, ein paar Zeilen C fuer die BSD-Sockets hier zu finden, immerhin ist die C-Version der BSD-Sockets ja quasi ihre Definition. Das Beispiel in Haskell sieht fuer mich offen gesagt eher danach aus, dass jemand dieser ausserhalb von Universitaeten "anwendungsfreien" Sprache unbedingt Gehoer verschaffen will. (nicht signierter Beitrag von 77.234.34.134 (Diskussion) 17:15, 21. Okt. 2008‎ (CEST))

du sagst es, das macht echt keinen sinn. Bitte ein einfaches c,java oder Pseudocode Beispiel (das ist aussagekräftiger als Haskell)--92.229.121.182 00:31, 17. Feb. 2009 (CET)

Absolut, ich unterstütze den Antrag :-) Und ich hab schon mit Haskell gearbeitet, ich verstehe was da steht. Aber ich wage zu behaupten dass 99% der Programmierer das nicht tun weil Haskell eine funktionale Sprache ist und sich auch die Syntax nicht selbst erklärt. Mal gucken ob ich die Zeit finde das in C neu zu schreiben. -- DarkDust 07:54, 17. Feb. 2009 (CET)

Ich finde es nicht schlecht, wenn es Beispiele in unterschiedlichen Sprachen geben würde. Gegen Haskell hätte ich dann gar nichts. -- Dk 14:24, 22. Sep. 2009 (CEST)

Zustimmung zum Löschen auch von mir. Nichts gegen Haskell, zumal man Client und Server auch allgemein verständlicher hätte implementieren können, aber durch die Verwendung von mapM_ und sequence_ macht der Code in einem Wiki-Artikel absolut keinen Sinn. Ganz davon absesehen ist er m.E. hässlich formatiert ;-) Java- oder Pseudocode fände ich weit sinnvoller. -- PyroPi 23:13, 2. Jun. 2010 (CEST)

Ich finde umgekehrt wird ein Schuh draus. Es sollten mehr Beispiele in unterschiedlichen Programmiersprachen geboten werden.

c, c++, java, perl, python, ruby,....

Kurzum ich bin ich bin zwar auch kein Freund von Haskell finde aber, dass ein kurzes und sogar funktionierendes Beispiel in diesem Artikel durchaus seine Berechtigung hat.

--Tschäfer (Diskussion) 23:43, 30. Mär. 2013 (CET)

Die Verständlichkeit für die meisten Programmierer in Frage gestellt zu sehen, zeigt doch überdeutlich, wie weit weg dieser Artikel von Allgemeinverständlichkeit und gut ist. Siehe auch: Was Wikipedia nicht ist. --84.157.197.143 21:26, 8. Jul. 2015 (CEST)

IPv6

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)

recv() / read(), blocking und non-blocking Verhalten

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)

Baustein "überarbeiten" noch aktuell?

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)

Hab ihn dann mal entfernt. --Noresoft (Diskussion) 15:40, 26. Nov. 2016 (CET)