Diskussion:Request for Comments
aus Wikipedia, der freien Enzyklopädie
Der RFC? Die RFC? Das RFC? -- stw (Talk) 12:18, 17. Jul 2004 (CEST)
- RFC=Request For Comments ("Bitte um Anmerkung"), demzufolge würde ich - so doof das sich anhört - die RFC sagen wollen... -- --GoreSplatter 02:32, 19. Jun 2006 (CEST)
Hallo, leider sind alle Links zu den RFCs kaputt. Wenn jemand die original Quelle kennt, bitte ändern oder mir mitteilen ich ändere das dann. --finanzer 23:45, 19. Jul 2004 (CEST)
Inhaltsverzeichnis |
[Bearbeiten] ietf.org / faqs.org
Hallo Gibt es einen besonderen Grund, dass in der deutschen Wikipedia die RFC-Links alle nach faqs.org gehen, wärend sie in der englischen auf ietf.org leiten. (vielleicht, um die Serverlast aufzuteilen?)
- Nein, mir fällt kein sinnvoller Grund ein, außer dass vielleicht vergessen wurde, eine Änderung der Interwiki-Tabelle in allen Wikipedias vorzunehmen. --Echoray 12:43, 27. Dez 2004 (CET)
[Bearbeiten] Discard-Service
Ist der Discard-Service wirklich nur ein Scherz? Ich denke nicht! Auch wenn es auf den ersten Blick keinen Sinn macht, ich kann mir doch durchaus einen Anwendungsfall vorstellen: Benchmarking. Wenn ich die theoretische Bandbreite einer Verbindung messen will, dann schicke ich die Pakete am besten zum discard-Port. Dann hat der Server keine große Arbeit mit den Daten (wegschmeissen geht sehr schnell), und auch der Client kann sehr viel Datenvolumen erzeugen. Die gemessene Bandbreite wird also kaum von der Performance von Client und Server beeinflusst, sondern nur von der Verbindung. [So kann man selbst mit einem 486 einen DoS auf eine megabit-schnelle Leitung veranstalten, vorausgesetzt, die Gegenstelle bietet "discard"]
- Dazu habe ich dann eine Frage: Wie möchtest Du die Bandbreite ermitteln, wenn Du keinerlei Antwort erhältst? Damit kannst Du höchstens feststellen, wie schnell Deine Software die Pakete erzeugenund versenden kann...
- Zur Performancemessung kannst Du vielleicht den Echo-Service oder Du benutzt Echo-Pakete auf ICMP-Ebene. --Herr Schroeder 14:58, 25. Apr 2005 (CEST)
-
- Der Discard Prozess ist kein scherz. Bereits 1972 wurd ein solcher für andere protokolle standardisiert, und dort auch bereits benötigt. Zur Performance messung in eine richtung bei TCP/IP wäre er durchaus zu gebrauchen, denn tcp/ip selbst macht hier einen ack und so kann man einfach die bandbreite in eine richtung messen (netcat /dev/zero nach host:port und dann schaun was rübergeht). weitere denkbare anwendungen sind, dass man programme hat die sehr einfach geschrieben sind und immer irgendwohin gesendet haben. discard services waren dann eine einfache möglichkeit eine sendekette abzubrechen (man bedenke, damals gabs wenig speicher und ein komplettes OS passte in 4kb). Im übrigen haben wir ja auch /dev/null, und das ist auch kein scherz. 84.176.207.202 14:49, 11. Aug 2006 (CEST)
[Bearbeiten] Weitere lustige RFCS
Ich denke einige dieser RFCS sollten auch als lustige mit aufgenommen werden:
- RFC1606 bietet eine historische perspektive von IPv9 (das es natürlich erst in der zukunft gebe könnte). Wohl eine kleine parodie auf den gigantischen addressraum von IPv6
- RFC1437 stellt ein MIME format für den transport von materie vor.
- RFC748 ist auch noch ein kleiner netter witz für diejenigen die noch telnet protokollo kennen
- RFC3252 beschreibt das BLOAT protokoll. Es ist eine binärimplementation von TCP/IP in XML. Sehr gelungen.
- RFC2550 beschäftigt sich mit tem Y10K problem.
- RFC1607 ist eine durch die zeit zurückgeschickte mail aus dem jahre 2023. Da sind wir schon auf dem mars.
- RFC3091 das Pi generation prtokoll ist auch niht wirklich ernst gemeint
- RFC2551 beschreibt den "Roman Standards process". recht gelungen, alle zahlen sind sogar in römisch
- RFC2325 greift wieder einmal den Kaffee auf
- RFC2321 würde viele hotlines überflüssig machen
Generell lohnt es sich die rfcs nach "April 1 " zu durchsuchen. (ok, einige weihnachts oder neujahr rfcs gehen dabei flöten). Die meisten linux distros haben ein rfc paket auf das man dann (z)grep loslassen kann 84.176.207.202 14:49, 11. Aug 2006 (CEST)
[Bearbeiten] RFC 1071
da fehlt aber rfc 1071. http://www.faqs.org/rfcs/rfc1071.html
