IP: Paket oder Datagram?

[Marco Moock]

Hallo zusammen,

in de.comp.os.unix.linux.misc gibt es gerade eine OT-Diskussion, ob der
Inhalt eines IPv4-Paketes packet oder datagram genannt wird. Damit ist
nicht UDP gemeint.

Hier der relevante Ausschnitt von mir:

Im RFC793 (uralt-RFC zu TCP) ist von "internet datagram envelope" die
Rede:

| TCP is based on concepts first described by Cerf and Kahn in [1].
| The TCP fits into a layered protocol architecture just above a basic
| Internet Protocol [2] which provides a way for the TCP to send and
| receive variable-length segments of information enclosed in internet
| datagram "envelopes".

ftp://ietf.org/rfc/rfc793.html

Im RFC 791 (uralt-RFC zu IPv4) auch:

| The internet protocol provides for transmitting blocks of data called
| datagrams [...]

ftp://ietf.org/rfc/rfc791.html

Von Packet aber auch, z.B. im Bezug zur maximalen Größe:

| In the routing of messages from one internet module to another,
| datagrams may need to traverse a network whose maximum packet size is
| smaller than the size of the datagram. To overcome this difficulty,
| a fragmentation mechanism is provided in the internet protocol.

Im IPv6-RFC ftp://ietf.org/rfc/rfc2460.html konnte ich das Wort
"datagram" nicht finden. Da scheint nur noch "packet" vorzukommen.

[Marco Moock]

Am Samstag, 17. September 2022, um 18:10:46 Uhr schrieb Marco Moock:

> Im IPv6-RFC ftp://ietf.org/rfc/rfc2460.html konnte ich das Wort
> "datagram" nicht finden. Da scheint nur noch "packet" vorzukommen.
>

Hier ist es ganz klar:
| packet - an IPv6 header plus payload.

[Bonita Montero]

Wie gut, dass Du das mal klärtst !
Macht ja dauernd Missverständnisse.

[Rupert Haselbeck]

Marco Moock schrieb:

Man sollte wohl nicht gar zu viel in Texte hineingeheimsen wollen,
welche offensichtlich in keiner Weise auf eine feste und eindeutige
Definition von "packet" oder "datagram" Wert legen und sie sogar recht
beiläufig in durchaus unterschiedlicher Bedeutung verwenden.
Man kommt aber glücklicherweise sowohl im Studium als auch einigen
Jahrzehnten des Berufslebens in allerlei Rollen vorzüglich ohne die
gekünstelte Unterscheidung zwischen Paketen, Segmenten und Datagrammen aus.
Die Welt ist bisher nicht untergegangen, obgleich der Begriff "Paket"
sowohl für TCP-Pakete als auch UDP-Pakete verwendet wird.
Es wäre fein, wenn man keine anderen Probleme zu bewältigen hätte :->

MfG
Rupert

[Marco Moock]

Am Samstag, 17. September 2022, um 20:40:04 Uhr schrieb Rupert
Haselbeck:

> Man sollte wohl nicht gar zu viel in Texte hineingeheimsen wollen,
> welche offensichtlich in keiner Weise auf eine feste und eindeutige
> Definition von "packet" oder "datagram" Wert legen und sie sogar
> recht beiläufig in durchaus unterschiedlicher Bedeutung verwenden.
> Man kommt aber glücklicherweise sowohl im Studium als auch einigen
> Jahrzehnten des Berufslebens in allerlei Rollen vorzüglich ohne die
> gekünstelte Unterscheidung zwischen Paketen, Segmenten und
> Datagrammen aus. Die Welt ist bisher nicht untergegangen, obgleich
> der Begriff "Paket" sowohl für TCP-Pakete als auch UDP-Pakete
> verwendet wird. Es wäre fein, wenn man keine anderen Probleme zu
> bewältigen hätte :->

Schon klar, aber ich nutze gerne die richtigen Fachbegriffe, denn das
reduziert die Verwirrung wenigstens etwas.

[Kay Martinen]

Am 17.09.22 um 21:05 schrieb Marco Moock:

> Am Samstag, 17. September 2022, um 20:40:04 Uhr schrieb Rupert
> Haselbeck:

>> gekünstelte Unterscheidung zwischen Paketen, Segmenten und
>> Datagrammen aus. Die Welt ist bisher nicht untergegangen, obgleich
>> der Begriff "Paket" sowohl für TCP-Pakete als auch UDP-Pakete
>> verwendet wird. Es wäre fein, wenn man keine anderen Probleme zu
>> bewältigen hätte :->
>
> Schon klar, aber ich nutze gerne die richtigen Fachbegriffe, denn das
> reduziert die Verwirrung wenigstens etwas.

Dann wirst du deinen Postboten nie fragen ob dein Paket mit einer
Korrekten Verifizierten Empfangsadresse versehen ist. Meiner Erfahrung
nach gibt es da die skurrilsten Schreibfehler. Ein Programm würde bei
Post für Marko Mock die Annahme verweigern. :-)

Ein Briefumschlag kann ebenso ein Daten-telegramm enthalten.

Päckchen=UDP, Paket (versichert)= TCP, Post= IP

Dein Lokaler Zustellstützpunkt= Segment...

???

Alle Fachbegriffe gelten nur in ihrem jew. Fach schon klar. Sie stammen
aber von irgendwas ab und das ist Zeitgeschichte. In deren Verlauf sich
Bedeutungen auch wandeln können oder der eine es so schreibt, der andere
so und beide doch das gleiche meinen. Evtl. Jahre auseinander.

Mit etwas Erfahrung erkennt man das irgendwann.

N.B. Beim TCP-Segment eingangs habe ich das Problem gesehen das m.E. ein
"Segment" nur ein Teil von etwas größerem ist. Aber eher im Sinne eines
Kuchensegments oder speichersegments. Also etwas das eher Endlich ist.
Ein TCP-Paket oder Datagramm ist aber m.E. eher nicht endlich in der
Summe seiner Teile. "Segment" sehe ich daher als unpassenden Begriff
dafür an.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Bonita Montero]

Wäre schön wenn das bei dir so wäre.

[Arno Welzel]

Marco Moock, 2022-09-17 18:10:

> Hallo zusammen,
>
> in de.comp.os.unix.linux.misc gibt es gerade eine OT-Diskussion, ob der
> Inhalt eines IPv4-Paketes packet oder datagram genannt wird. Damit ist
> nicht UDP gemeint.

Datagram ist die alte Bezeichung. Aber "Packet" ist exakt das selbe.

> Hier der relevante Ausschnitt von mir:
>
> Im RFC793 (uralt-RFC zu TCP) ist von "internet datagram envelope" die
> Rede:
>
> | TCP is based on concepts first described by Cerf and Kahn in [1].
> | The TCP fits into a layered protocol architecture just above a basic
> | Internet Protocol [2] which provides a way for the TCP to send and
> | receive variable-length segments of information enclosed in internet
> | datagram "envelopes".
>
> ftp://ietf.org/rfc/rfc793.html

FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht mehr
unterstützt.

<https://ietf.org/rfc/rfc793.html>


--
Arno Welzel
https://arnowelzel.de

[Marco Moock]

Am Sonntag, 18. September 2022, um 02:28:40 Uhr schrieb Kay Martinen:

> N.B. Beim TCP-Segment eingangs habe ich das Problem gesehen das m.E.
> ein "Segment" nur ein Teil von etwas größerem ist. Aber eher im Sinne
> eines Kuchensegments oder speichersegments. Also etwas das eher
> Endlich ist. Ein TCP-Paket oder Datagramm ist aber m.E. eher nicht
> endlich in der Summe seiner Teile. "Segment" sehe ich daher als
> unpassenden Begriff dafür an.

Es gibt Sequenznummern, die haben eine Länge, damit ist das auch
endlich. man kann natürlich dann die Verbindung schließen und eine neue
aufbauen.

[Marco Moock]

Am Sonntag, 18. September 2022, um 10:13:43 Uhr schrieb Arno Welzel:

> FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht mehr
> unterstützt.

FTP funktioniert wunderbar, wenn Browser wie Firefox oder
Chrome das nicht mehr können - mir egal, ich lasse mir von beiden nicht
das Leben diktieren.
Zur Not wget nutzen, nach - ausgeben und an more pipen.

[Bonita Montero]

Am 18.09.2022 um 11:17 schrieb Marco Moock:
> Am Sonntag, 18. September 2022, um 10:13:43 Uhr schrieb Arno Welzel:
>
>> FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht mehr
>> unterstützt.
>
> FTP funktioniert wunderbar, wenn Browser wie Firefox oder
> Chrome das nicht mehr können - mir egal, ich lasse mir von
> beiden nicht das Leben diktieren.

Naja, dass Du bei solchen Gegebenheiten von "das Leben diktieren"
schreibst wundert mich nicht. Du rennst vermutlich wie viele Nerds
viel mit einem latenten Gefühl des Fremd-bestimmt-seins durch die
Gegend das nur nach äußeren Konkretisierungen sucht.

Auf jeden Fall ist FTP schon echt nen Murks-Protokoll mit seinen
zwei Datenströmen und dem nicht normierten Content für die Über-
tragung beim LIST-Kommando; wirkt für mich eher alles wie ein
Hack. Wär das kein Murks, dann wär es ja auch nicht so weitgehend
ausgestorben.

> Zur Not wget nutzen, nach - ausgeben und an more pipen.

Ich weiß es nicht, aber ich bin mir ziemlich sicher, dass
wget auch eine Umleitung in eine Datei per Option kennt;
würde mich wundern wenn nicht.

[Arno Welzel]

Marco Moock, 2022-09-18 11:17:

> Am Sonntag, 18. September 2022, um 10:13:43 Uhr schrieb Arno Welzel:
>
>> FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht mehr
>> unterstützt.
>
> FTP funktioniert wunderbar, wenn Browser wie Firefox oder
> Chrome das nicht mehr können - mir egal, ich lasse mir von beiden nicht
> das Leben diktieren.

Gopher ist dann auch für Dich auch noch relevant, nur weil Du Software
hast, die das unterstützt?

> Zur Not wget nutzen, nach - ausgeben und an more pipen.

Wozu? HTTP existiert.

[Marco Moock]

Am Montag, 19. September 2022, um 14:02:29 Uhr schrieb Arno Welzel:

> Marco Moock, 2022-09-18 11:17:
>
> > Am Sonntag, 18. September 2022, um 10:13:43 Uhr schrieb Arno Welzel:
> >
> >> FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht
> >> mehr unterstützt.
> >
> > FTP funktioniert wunderbar, wenn Browser wie Firefox oder
> > Chrome das nicht mehr können - mir egal, ich lasse mir von beiden
> > nicht das Leben diktieren.
>
> Gopher ist dann auch für Dich auch noch relevant, nur weil Du Software
> hast, die das unterstützt?

Ich habe schon öfter Gopherlöcher besucht (erst so ab ca. 2020), ich
sehe kein Problem in dem Protokoll.

> > Zur Not wget nutzen, nach - ausgeben und an more pipen.
>
> Wozu? HTTP existiert.

Weil FTP Vorteile wie ein gescheites directory listing hat.
Zudem muss nicht alles über HTTP abgewickelt werden, weil es das gibt
und Firmen wie Google der Meinung sind, alles müsse über HTTP laufen.

[Arno Welzel]

Marco Moock, 2022-09-19 14:38:

> Am Montag, 19. September 2022, um 14:02:29 Uhr schrieb Arno Welzel:
>
>> Marco Moock, 2022-09-18 11:17:
>>
>>> Am Sonntag, 18. September 2022, um 10:13:43 Uhr schrieb Arno Welzel:
>>>
>>>> FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht
>>>> mehr unterstützt.
>>>
>>> FTP funktioniert wunderbar, wenn Browser wie Firefox oder
>>> Chrome das nicht mehr können - mir egal, ich lasse mir von beiden
>>> nicht das Leben diktieren.
>>
>> Gopher ist dann auch für Dich auch noch relevant, nur weil Du Software
>> hast, die das unterstützt?
>
> Ich habe schon öfter Gopherlöcher besucht (erst so ab ca. 2020), ich
> sehe kein Problem in dem Protokoll.
>
>>> Zur Not wget nutzen, nach - ausgeben und an more pipen.
>>
>> Wozu? HTTP existiert.
>
> Weil FTP Vorteile wie ein gescheites directory listing hat.

Und das benötigt man, um auf *ein* Dokument zu verweisen, wie
<ftp://ietf.org/rfc/rfc793.html>?

Und was ist an <https://www.ietf.org/rfc/> nicht "gescheit"? Dass Du das
Listing nicht selber erzeugt hast sondern über eine URL abrufen kannst?

> Zudem muss nicht alles über HTTP abgewickelt werden, weil es das gibt
> und Firmen wie Google der Meinung sind, alles müsse über HTTP laufen.

Was Google will ist mir egal.

Ich sehe nur den technischen Murks bei FTP mit separater Steuer- und
Datenverbindung und dem Krampf mit "aktiver"/"passiver" Verbindung und
dem damit einhergehenden Herumgebastele mit "NAT-Helpern" und ähnlichem
Murks. Dass die Unterstützung für sowas in Browsern abgeschafft wurde,
ist vollkommen korrekt.

[Bonita Montero]

Am 19.09.2022 um 14:38 schrieb Marco Moock:
> Am Montag, 19. September 2022, um 14:02:29 Uhr schrieb Arno Welzel:
>
>> Marco Moock, 2022-09-18 11:17:
>>
>>> Am Sonntag, 18. September 2022, um 10:13:43 Uhr schrieb Arno Welzel:
>>>
>>>> FTP ist weitgehend tot und wird zurecht von vielen Browsern nicht
>>>> mehr unterstützt.
>>>
>>> FTP funktioniert wunderbar, wenn Browser wie Firefox oder
>>> Chrome das nicht mehr können - mir egal, ich lasse mir von beiden
>>> nicht das Leben diktieren.
>>
>> Gopher ist dann auch für Dich auch noch relevant, nur weil Du Software
>> hast, die das unterstützt?
>
> Ich habe schon öfter Gopherlöcher besucht (erst so ab ca. 2020), ich
> sehe kein Problem in dem Protokoll.

Das ist immer eine schlechte Strategie, die Relevanz einer abstrusen
These mit der Relevanz einer noch abstuseren zu rechftfertigen.

>
>>> Zur Not wget nutzen, nach - ausgeben und an more pipen.
>>
>> Wozu? HTTP existiert.
>
> Weil FTP Vorteile wie ein gescheites directory listing hat.

Kann WebDAV, was ja eine kleine Erweiterung auf HTTP-Ebene ist,
auch, sogar viel besser bzw. das von FTP ist gar nicht gescheit
weil nicht normiert.

[Ignatios Souvatzis]

Rupert Haselbeck wrote:

> Man sollte wohl nicht gar zu viel in Texte hineingeheimsen wollen,
> welche offensichtlich in keiner Weise auf eine feste und eindeutige
> Definition von "packet" oder "datagram" Wert legen und sie sogar recht
> beiläufig in durchaus unterschiedlicher Bedeutung verwenden.

Bis hierhin einverstanden...

> Man kommt aber glücklicherweise sowohl im Studium als auch einigen
> Jahrzehnten des Berufslebens in allerlei Rollen vorzüglich ohne die
> gekünstelte Unterscheidung zwischen Paketen, Segmenten und Datagrammen aus.

Ein TCP-Segment ist etwas konzeptionell anderes als ein UDP-Paket
oder IP-Paket (da, ich habe beide gleich benannt), nämlich die
Segmetierung eines beliebig (und von vorneherein erstmal unbestimmt
langen) Bytestroms.

Wenn ich also über TCP-Interna rede, (z.B. zur Analyse von Problemen
anhand eines Mitschnitts), werde ich tunlichst von Segmenten sprechen.

Gruesse,
-is

[Ignatios Souvatzis]

Bonita Montero wrote:

> Auf jeden Fall ist FTP schon echt nen Murks-Protokoll mit seinen
> zwei Datenströmen und dem nicht normierten Content für die Über-
> tragung beim LIST-Kommando; wirkt für mich eher alles wie ein
> Hack. Wär das kein Murks, dann wär es ja auch nicht so weitgehend
> ausgestorben.

HTTP ist tot. Der content ist beim Auflisten von Inhalten ungenormt,
es kann alles von einer Textliste bis hin zu einem Kontaktabzug von
Bildern da sein.

-is

[Bonita Montero]

Bei FTP ist es ja so, dass es ein LIST gibt, aber das was man darauf
zurückkommt nicht normiert ist. Bei HTTP gibt's nichts dergleichen.
Aber es gibt eben WebDAV, was ja auf HTTP aufbaut, und das hat eine
normierte Schnittstelle für Ordner-Inhalte. Von daher weiß ich nicht
wo jetzt bei HTTP an der Stelle das Problem sein soll.

[Arno Welzel]

Ignatios Souvatzis, 2022-12-16 14:29:

Was auch korrekt ist - TCP verwendet Segmente und keine Pakete. Deshalb
gibt es auch die MSS - "Maximum Segment Size" - auf die sich Sender und
Empfänger einigen.

Weiterhin kann man anhand der Sequenznummer im TCP-Header die Segmente
bei Bedarf in die richtige Reihenfolge bringen.

[Arno Welzel]

Ignatios Souvatzis, 2022-12-16 14:32:

"Auflisten von Inhalten" ist aber keine Anwendung, für die HTTP
entwickelt wurde, im Gegensatz zu FTP wo es das LIST-Kommando gibt.

Weiterhin ist der Content bei HTTP sehr wohl genormt, angefangen bei den
Content-Type-Headern, die dem Client exakt mitteilen, was er zu erwarten
hat. Etwas vergleichbares im Sinne von "Dateiliste kommt jetzt im Format
entsprechend des Typs XYZ" gibt es bei FTP schlicht nicht. Clients, die
solche Listen inhaltlich verarbeiten und nicht nur als Text anzeigen
wollen, werden mehr oder weniger "raten", mit welche der existierenden
Servervarianten sie es wohl zu tun haben.

[Ignatios Souvatzis]

Ignatios Souvatzis wrote:
> Rupert Haselbeck wrote:
>
>> Man sollte wohl nicht gar zu viel in Texte hineingeheimsen wollen,
>> welche offensichtlich in keiner Weise auf eine feste und eindeutige
>> Definition von "packet" oder "datagram" Wert legen und sie sogar recht
>> beiläufig in durchaus unterschiedlicher Bedeutung verwenden.
>
> Bis hierhin einverstanden...

Bei längerem Nachdenken wollte ich mein Einverständnis *eigentlich*
zurückziehen --- immerhin heisst UDP nicht nur User Datagram protocol,
es ist sogar eins:

DESCRIPTION
UDP is a simple, unreliable datagram protocol [...] [1]

ein Socket zum versenden solcher wird mit
socket(AF_INET6, SOCK_DGRAM, 0);
socket(AF_INET, SOCK_DGRAM, 0);
socket(AF_ISO, SOCK_DGRAM, 0);

erzeugt und nicht etwa mit
socket(AF_INET6, SOCK_PACKET, 0);

--- *aber* an fast allen anderen stellen ist von packets die Rede, z.B.

[...]the connect(2) call may also be used to fix the
destination for future packets[...]

Zu allem Überfluss heisst die Abstraktion fuer geordnete ... Pakete ...
nicht etwa SOCK_SEQDGRAM, sondern SOCK_SEQPACKET...

Ohne jetzt in antiken RFCs (pre-768) rueckwaerts recherchiert zu
haben, vermute ich "datagram" in einem historisch weitgehend
verdrängten Regiolekt.

[1] man 4 udp

-is