Mein DSL

Du hast mir gar nichts "gezeigt".

Du bist nur nicht auf den Punkt gekommen. Der Punkt heißt Zugriffstransparenz.

Und nun darfst Du Dich mit Deinen Mitgurglern an Wikipedia abarbeiten, wovon ich rede. Nicht, um mir etwas zu zeigen, mir sind die Dinge bekannt. Aber vielleicht kommen auf Dich einige Aha-Erlebnisse zu.

Es kann sein, daß die in diesem Thread nicht vorkommen.

Es kann überhaupt sein, daß wir hier nicht jedem Menschen, der neu in die Gruppe einsteigt, Grundlagenwissen erklären, daß voraussetzbar ist und das sich Menschen erarbeiten können.

Ich bin im Augenblick nicht ganz sicher, wer hier überfordert ist.

Am 16.08.2012 21:40, schrieb Hausmeister:

Im Moment eindeutig ich. Hab zwar schon Übung drin, im Netz aus 95% Trollerei echt relevante Informationen 'rauszufischen, aber manchmal nützt nicht mal das was. :-)

Dann frag nicht so dämlich.

Doch, alles schon vorgekommen. Deine Überheblichkeit und Ignoranz stinkt zum Himmel.

Wenn ihr (statt wieder wochenlang zu rechnen), mal eine Anwendung dafür bereitstellen könnt (in dem Sinne: "Installiere dir das und das Paket, mach' die und die Änderungen in der und der Konfigurationsdatei, und der 'Flaschenhals' upload ist beseitigt" - also die einzige "Transparenz", die was bringen könnte), nehme ich "Ingoranz" und "Arroganz" zurück, und wir würden uns auch über einen angemessenen Preis einig. Und ihr sicher nicht nur mit mir. :-)

TCP wurde für symmetrische Leitungen entworfen. Standardkonforme Implementierungen verhalten sich ungünstig, wenn eine ADSL (niedriger Durchsatz in eine Richtung, hohe Latenz) im Route-Weg ist.

RFC-widrige-Implementierungen haben im Internet nichts zu suchen.

Joseph

Und so sprach Joseph Terner:

Da TCP als Transportprotokoll ein leitungsunabhängiges (übertragungswegunabhängiges) Protokoll ist, kann es nicht für irgend welche physischen Einschränkungen entworfen sein.

Roland

Am 16.08.2012 22:40, schrieb Joseph Terner:

Es gibt also auch andere?

Eine Verbindung zum FTP - Server auch nicht, oder? :-)

Joseph Terner schrieb:

er

TCP interessiert sich =FCberhaupt nicht f=FCr die darunterliegende Leit= ung. Es=20 wurde selbstverst=E4ndlich auch nicht speziell f=FCr bestimmte=20 Leitungseigenschaften konzipiert

Das stimmt, tut aber hier =FCberhaupt nichts zur Sache

MfG Rupert

Hartmut Kraus schrieb:

=20

Mit "mounten" hat das nichts zu tun. Wenn du auf einem Rechner einen=20 dort installierten ftp-Server mit einem ftp-Client ansprichst, will der=20 =FCblicherweise deinen Benutzernamen und dein Passwort wissen. Danach=20 kannst du auf Verzeichnisse zugreifen, die der ftp-Server f=FCr diesen=20 Zugriff freigegeben hat.

Der "mount"-Befehl bezieht sich =FCblicherweise auf Ger=E4te und=20 Verzeichnisse, die ins eigene Dateisystem integriert werden, so da=DF sic= h=20 ein einheitlicher Verzeichnisbaum ergibt, egal, wo die Rechner stehen.

Holger

TCP wurde zu einer Zeit entworfen, als Übertragungsbandbreite noch ein extrem knappes Gut war. Die Wahrscheinlichkeit einer symmetrischen Verteilung der für die TCP-Versuche *nutzbaren* Bandbreite dürfte damals nahe bei Null gelegen haben.

Insofern scheint mir die obige These etwas gewagt.

Ja - wenn die ohnehin schmalbandige Richtung in Congestion getrieben wird, während die breitbandige Richtung noch reichlich Luft hat, bleibt ein Teil davon ungenutzt.

Ob das in typischen ADSL-Anwendungsszenarien tatsächlich ungünstig ist, sei mal dahingestellt. Upload-intensive Anwendungsprogramme bieten fast immer eine Möglichkeit, die Datenrate so zu begrenzen, daß der Upstream nicht in Congestion gerät. Und bessere Router beherrschen zudem Traffic-Shaping.

Willkommen in der Realität!

Hergen

Wo habe ich denn dämlich gefragt?

Ich habe Dich auf einen Fehler hingewiesen. Ich habe Dich darauf hingewiesen, daß Du nicht weißt, was "mounten" eines Dateisystems bedeutet.

Holger schrieb:

ich

Man kann auch "sshfs" (f=FCr sftp) und "curlftpfs" verwenden, dabei=20 benutzt man jedoch nicht den normalen mount-Befehl, aber man h=E4ngt eine= =20 FTP-Dateisystem in seinen eigenen Verzeichnisbaum ein.

Ein smbfs (smb-share, Windows-Freigabe) kann man =FCbrigens sogar mit=20 mount einbinden.

Guido

Ich bin weder überheblich noch ignorant.

Und nun hör auf, die Leute hier zu beleidigen. Du solltest die Zeit sinnvoller nutzen und Einsteigerlitertur lesen.

ad 1: Wo steht das?

ad 2: Es ist egal, wofür es entworfen wurde, es tut auf asymmetrischen Leitungen einwandfrei.

Beleg?

Und hier erwarte ich a) einen Beleg für Deine usprüngliche Aussage, nämlich daß die Asymmetrie das Problem ist, b) als Beleg entweder eine einschlägige Primärquelle oder c) eine durchgestochene Begründung.

Joseph, bevor Du mit Kampfbegriffen wie "RFC" kommst, solltest Du die RFC Lage erstmal kennen. Und in Deinem bisherigen Vortrag habe ich vollmundige Behauptungen gelesen, dafür aber kein Wort zur RFC Lage.

Das kann ich so ohne weiteres nicht stehen lassen. TCP ist ein generisches Protokoll, und da kann es sehr wohl sein, und ist auch so, daß es mit manchen konkreten Situationen besser zurecht kommt als mit anderen.

Wobei die Asymmetrie in der Datenrate nun aber leider zu den Dingen gehört, die TCP nun am allerwenigsten stören.

Aber da müssten wir nun wirklich in die Details rein, und das wird dann hier off topic.

Und ist auch leider ziemlich akademisch.

In der Tat lassen viele RFC Aussagen durchaus einen gewissen Spielraum, aber auch sonst würden wir uns vermutlich verwundert die Augen reiben, vie wenig der TCP Verbindungen, die hier im Rahmen dieses Threads genutzt wurden, RFC konform waren.

(Es ist z.B. ein ziemlich offenes Geheimnis, jetzt mache ich mir aber nicht die Mühe, die Originalarbeiten rauszusuchen, das steht in jeder brauchbaren Netzwerkvorlesung drin, daß schon die Timeoutberechnung bei Linux definitiv _nicht_ RFC konform ist.)

Vielleicht nur mal als Einstieg:

Ich begenge selbst in Fachkreisen der etwas drolligen Auffassung, es gebe bei TCP so etwas wie eine "Realität" im Sinne einer standardisierten, für alle bindenden Implementierung.

Ich weiß nicht mal, wie weit das wünschenswert oder erwartbar ist.