Moin
Wieviel Overhead, sprich Zusatztransfer, erzeugt eine nicht benutzte TCP/IP-Verbindung ?
Oder anders gefragt : Wieviel KB pro Stunde „verbraucht“ wenn man eine TCP/IP-Verbindung ungenutzt stehen lässt ?
Hängt das vom Netzwerk ab ?
wenn ja: mich interessiert hauptsächlich Modem (DFÜ) und Ethernet (100MBit über mehrere Switche).
cu
Hi,
IMHO sieht das so aus: TCP/IP bietet eigentlich gar keine Verbindungen (wie zB Telefon), sondern übermittelt Datenpakete an einen Empfänger. Werden keine Daten geschickt, gibts auch keine Pakete.
Natürlich können Protokolle aus höheren Schichten Funktionen haben, bei denen sich die Partner in regelmäßigen Abständen rufen, um sicherzugehen, daß der andere noch „lebt“, aber dafür ist nicht TCP/IP verantwortlich, sondern eben irgendein darauf aufsetzendes Protokoll (bzw. Anwendung).
LG
Stuffi
glaub ich nicht ganz/Zusatzfragen
Hi,
IMHO sieht das so aus: TCP/IP bietet eigentlich gar keine
Verbindungen (wie zB Telefon), sondern übermittelt Datenpakete
an einen Empfänger. Werden keine Daten geschickt, gibts auch
keine Pakete.
Das kann so nicht ganz stimmen:
Habe 2 PC’s über switch verbunden, nennen wir sie A und B
Wenn ich eine Verbindungen aufbaue von A nach B (keine Daten verschicke), und dann den Ethernet-Stecker zwischen B und switch rausziehe (kein Verbindungsaubau, und die Ethernetkarte von A kanns eigentlich nicht merken) meldet aber das Socket dem Prog. auf A dass die Verbingung weg ist. eigentlich immer sofort.
Wie geht das ?
meldet das der Switch ?
klappt das auch über’s internet (wenn 20-30 Hops dazwischenliegen) ?
danke & cu.
Ich habe nicht wirklich viel Ahnung von der Materie, aber ich hätte erstmal so geantwortet wie Stuffi:
IMHO sieht das so aus: TCP/IP bietet eigentlich gar keine
Verbindungen (wie zB Telefon), sondern übermittelt Datenpakete
an einen Empfänger. Werden keine Daten geschickt, gibts auch
keine Pakete.Das kann so nicht ganz stimmen:
Habe 2 PC’s über switch verbunden, nennen wir sie A und B
Wenn ich eine Verbindungen aufbaue von A nach B (keine Daten
verschicke), und dann den Ethernet-Stecker zwischen B und
switch rausziehe (kein Verbindungsaubau, und die Ethernetkarte
von A kanns eigentlich nicht merken) meldet aber das Socket
dem Prog. auf A dass die Verbingung weg ist. eigentlich immer
sofort.Wie geht das ?
Gute Frage: vielleicht schreit in der Tat der Switch? 'Mal mit einem Sniffer schauen?
klappt das auch über’s internet (wenn 20-30 Hops
dazwischenliegen) ?
Das hoffe ich nicht.
Hier mal getestet:
„telnet mailserver 25“
[Antwort des Servers abgewartet]
[Kabel zwichen den beiden Kisten 'rausgerupft]
EHLO
[Kabel wieder hereingesteckt]
[Antwort des Servers auf „EHLO“ erschien].
„Das ist auch gut so“, schließlich soll TCP/IP ja störungssicher sein.
IMHO sieht das so aus: TCP/IP bietet eigentlich gar keine
Verbindungen (wie zB Telefon), sondern übermittelt Datenpakete
an einen Empfänger. Werden keine Daten geschickt, gibts auch
keine Pakete.Das kann so nicht ganz stimmen:
Habe 2 PC’s über switch verbunden, nennen wir sie A und B
Wenn ich eine Verbindungen aufbaue von A nach B (keine Daten
verschicke), und dann den Ethernet-Stecker zwischen B und
switch rausziehe (kein Verbindungsaubau, und die Ethernetkarte
von A kanns eigentlich nicht merken) meldet aber das Socket
dem Prog. auf A dass die Verbingung weg ist. eigentlich immer
sofort.Wie geht das ?
meldet das der Switch ?
Hallo!
Ein einfacher Socket merkt nicht, dass die Verbindung unterbrochen ist. Er kann dies nur merken, wenn er neben den Nutzdaten regelmäßig Daten zur Kontrolle der Verbindung verschickt. Empfängt er nach einem Timeout keine Antwortpakete, ist die Verbindung fehlerhaft.
Bedenke: Ein Socket ist eine Abstraktion. Er bietet wesentlich mehr Funktionalität als reines TCP/IP. Das merkst Du z.B. schon daran, dass Du beliebige Daten in einen Socket schreiben kannst, ohne sie beispielsweise in Pakete zu zerlegen, etc…
CU
Markus
Moin,
ich muß da den vorigen Postern zustimmen…ohne traffic kein overhead…der overhead bei tcp/ip frames besteht ja hauptsächlich aus Kontrollinformationen o.Ä.
Ein kleines Beispiel:
Wenn ich ein Daten"paket" von 1 byte Länge in die TCP-Schicht einfülle,
kommen:
mind. 20 byte TCP-header und
mind. 20 byte IP-header und
Die Maximallänge von so einem Paket beträgt 576 byte, also kann man 1
bis ca. 536 byte Daten pro Paket verschicken.
Kein Verkehr…kein overhead…außer es werden, wie schon gesagt, solche keep alive pakets versendet die aber mit tcp/ip nicht viel am hut haben…
Gruß INDY
Das kann so nicht ganz stimmen:
Habe 2 PC’s über switch verbunden, nennen wir sie A und B
Wenn ich eine Verbindungen aufbaue von A nach B (keine Daten
verschicke), und dann den Ethernet-Stecker zwischen B und
switch rausziehe (kein Verbindungsaubau, und die Ethernetkarte
von A kanns eigentlich nicht merken) meldet aber das Socket
dem Prog. auf A dass die Verbingung weg ist. eigentlich immer
sofort.Wie geht das ?
Hallo Pumpkin
Windows kontrolliert die Verbindung, bei mir (XP) gibt es eine Fehlermeldung, diese Balloon-Tips, wenn die Netzwerkverbindung unterbrochen wird.
Gruß
Rainer
Habe 2 PC’s über switch verbunden, nennen wir sie A und B
Wenn ich eine Verbindungen aufbaue von A nach B (keine Daten
verschicke), und dann den Ethernet-Stecker zwischen B und
switch rausziehe (kein Verbindungsaubau, und die Ethernetkarte
von A kanns eigentlich nicht merken) meldet aber das Socket
dem Prog. auf A dass die Verbingung weg ist. eigentlich immer
sofort.
Wie geht das ?
meldet das der Switch ?
klappt das auch über’s internet (wenn 20-30 Hops
dazwischenliegen) ?
Hmm, interessante Frage,
Das SMB-Protokoll zwischen 2 Windows-PCs versendet zwar auch bei mir regelmäßig keep alive - Pakete, aber nur ca all 30sek (activity leuchte), das Abstecken wird aber sofort erkannt…
Ich denke, das ist keine TCP/IP-Funktion, sondern eine des darunterliegenden Ethernet-Standards, da kenn ich mich aber nicht aus.
Übers Internet wirds wahrscheinlich nicht klappen, da die Router AFAIK nur die TCP/IP Pakete weiterleiten, und den Ethernet-Overhead weglassen.
LG
Stuffi
Danke an alle und …
Dieser „Erreichbarkeisttest“ ist eine Funktionalität des Ethernet und hat nichts mit IP zu tun. (und funzt nicht zuverlässig über mehr als 2 Hops).
cu