Re: Netstat zeigt UDP 'established'

Mario 'BitKoenig' Holbe <Mario.Holbe@xxxxxxxxxxxxx>:
Juergen P. Meier <nospam-1984@xxxxxxxx> wrote:
Mario 'BitKoenig' Holbe <Mario.Holbe@xxxxxxxxxxxxx>:
Bei datagram sockets weiss der Kern halt nur auf "Client"-Seite, ob
sie connected sind und kann sie daher auch nur dort so anzeigen.
GNA. Wie koennen diese $%#!@$# Spacken dann nur Semantiken von
TCP entleihen um das zu implementieren?

TCP ist ein Kommunikationsprotokoll, sockets sind eine
Programmierschnittstelle. Beide haben eine voellig eigene Semantik und

Auch die TCP Programmierschnittstelle mit ihrer Semantik ist im
Standard skizziert. Wir sind hier schliesslich nicht bei ISO/OSI.

beider Semantik hat grundsaetzlich erstmal nichts miteinander zu tun.

Doch: Sockets sind eine Abbildung der Protokollsemantik auf die
Schnittstellenebene.

Dass ein STREAM socket in der INET/INET6 Adress-Familie mittels TCP
implementiert wird und dass deshalb diese konkreten sockets dann auch
die TCP Zustandsmaschine kennen, ist halt leider so.

Du verwechselst jetzt aber etwas: Es wurde nicht zuerst das Auto
erfunden und dazu dann das Rad.

STREAM sockets sind nur /eine/ Implementierung von TCP. BSD Sockets
eine andere (aeltere btw).

Die Implementierung von connect() fuer STREAM sockets in AF_INET ist
halt etwas aufwendiger und fuehrt ueber mehr Zwischenzustaende als die
fuer DGRAM sockets.

Fuer DGRAM sockets ist das ein Hack um eine semantisch verschiedene,
effektiv aber aehnliche Semantik in ein bereits vorhandenes Konzept
zu quetschen, anstatt ein passendes einfach neu zu implementieren.

Als Gruende dafuer kommt eigentlich nur Faulheit in betracht. Weder
Interoperabilitaet (mit was? Anderen UDP-Connect-Implementierungen
etwa?) noch API-Konformitaet (zu welchem Standard?
einem Linux-Industrie-Standard vielleicht?) kommen sonst dafuer in Frage.
Auch Code-Refacturing kann niemand ernsthaft hierbei als Argument
vorbringen.

Ist es denn so schwer 3 Gramm Gehirnmasse zusammenzunehmen und sich
eine passende eigene Semantik auszudenken?

Ach, ich kommentiers einfach nicht. Oder doch? Naja... Layer und so.
Kontext und so.

Manchmal sind die banalsten Gruende die, die der Wahrheit am naechsten kommen.

Denn trotz bindung (connect call) ist das protokolltechnisch *nicht*
verbunden.

Ja, UDP sockets koennen halt auf einer Seite connect()ed sein und auf
der anderen nicht, so what?

Der Zustand "ESTABLISHED" ist gemaess IETF Standard aber explizit genau
anders definiert.

Es muss auf der Gegenseite keinen persistenten
entsprechenden socket geben (wie z.B. bei TCP).

Es muss bei TCP auf der Gegenseite auch ueberhaupt keinen socket geben.

Doch, muss es. Das ist naemlich so im TCP Standard definiert.

Es koennte da auch einen TLI oder XTI transport endpoint geben oder einen

Aus Sicht des Protokollstandards sind auch diese Transport Endpoints Sockets.

Du machst hier den gleichen Fehler wie einige andere auch, und
verwechselst TCP Sockets aus der Protokolldefinition mit gleichnamigen
Implementierungen in Betriebssystemen. Nur weil ein TCP Socket unter
Kernen mit BSD oder SysV-STREAM-semantiken zufaellig auch in dieser
Schicht "Socket" genannt werden, ziehst du faelschlicherweise den
Rueckschluss, dass alles andere (was nicht "socket" getauft wurde)
kein TCP-Socket waere. (Zugegeben, es mag verwirren, dass die erste
und jahrelang einzige TCP-Implementierung Sockets waren).

Port (Vorsicht, hier droht derselbe Kontext-Fehler wie bei "ESTABLISHED"

Der Zustand "Established" ist bei der TCP/IP Protokollsuite klar definiert.

Was die Socket-API damit macht, ist eine voellig andere Geschichte.
Und wenn sie hergeht, und "Established"-Zustaende wo draufmalt, wo sie
vom Protokollstandard nichts verloren haben, dann ist sie schlicht und
einfach Mangelhaft.

:), siehe z.B. http://en.wikipedia.org/wiki/Computer_port_(software))

Wikipedia...

oder einen channel endpoint oder auch einfach gar keine abstrakte
API-Repraesentation.

Man koennte auch sagen, es ist ein Spezialfall von TCP sockets, dass ein
connect() auf der einen Seite einen neuen connected socket auf der
anderen Seite erzeugt. Und dann koennte man sich darueber aufregen, dass
die socket API durch ein solches Verhalten ziemlich angreifbar wird -
und man haette damit nichtmal Unrecht.

Ein kleiner Patch in netstat, um bei DGRAM Sockets mit gefuellter
connect-struktur anstatt der hier semantisch wie logisch an der Stelle
falschen Zeichenkette "ESTABLISHED" auszugeben, z.B. "SPECIFIC"
oder "QUALIFIED" oder ein anderes passendes Verb aus der jeweiligen
zu nehmen, wuerde dieses Problem und aehnliche Fragen wie die des OP
hinfaellig machen.

Das dann bei Linux in der Kernelstruktur die gleiche Zahl steht, wie
es bei STREAM-Sockets dem ESTABLISHED-Zustand der Fall ist, darf dann
auch eine Obskuritaet dieser Implementierung sein.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
.

Relevant Pages