<?xml version="1.0" encoding="ISO-8859-15"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Kommentare zu: Datenschaufleritis</title>
	<atom:link href="http://dreamforge.wordpress.com/2007/09/28/datenschaufleritis/feed/" rel="self" type="application/rss+xml" />
	<link>http://dreamforge.wordpress.com/2007/09/28/datenschaufleritis/</link>
	<description>Geistige Ergüsse und Zeugs</description>
	<lastBuildDate>Fri, 14 Aug 2009 21:44:39 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Von: Woo</title>
		<link>http://dreamforge.wordpress.com/2007/09/28/datenschaufleritis/#comment-5</link>
		<dc:creator>Woo</dc:creator>
		<pubDate>Mon, 01 Oct 2007 21:06:09 +0000</pubDate>
		<guid isPermaLink="false">http://dreamforge.wordpress.com/2007/09/28/datenschaufleritis/#comment-5</guid>
		<description>UDP waere als Option bei NFS machbar.. nur habe ich keine Ahnung, wie gut das den potentiellen Paketverlust wegsteckt. Vollstaendig verlorengehen darf da kein Paket, und wenn im Falle eines erkannten Fehlpakets die ganze Datei neu angefordert wird, habe ich mit meinen 10-20GB Kolossen wieder die A*Karte.
Ich werds wohl mal testen. Auch auf der Experimentierliste stehen Veraenderungen an der ACK-Fenster-Groesse.. mal schaun wie weit ich das ausreizen kann bevors unzuverlaessig wird.</description>
		<content:encoded><![CDATA[<p>UDP waere als Option bei NFS machbar.. nur habe ich keine Ahnung, wie gut das den potentiellen Paketverlust wegsteckt. Vollstaendig verlorengehen darf da kein Paket, und wenn im Falle eines erkannten Fehlpakets die ganze Datei neu angefordert wird, habe ich mit meinen 10-20GB Kolossen wieder die A*Karte.<br />
Ich werds wohl mal testen. Auch auf der Experimentierliste stehen Veraenderungen an der ACK-Fenster-Groesse.. mal schaun wie weit ich das ausreizen kann bevors unzuverlaessig wird.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Zarquod</title>
		<link>http://dreamforge.wordpress.com/2007/09/28/datenschaufleritis/#comment-3</link>
		<dc:creator>Zarquod</dc:creator>
		<pubDate>Mon, 01 Oct 2007 18:10:26 +0000</pubDate>
		<guid isPermaLink="false">http://dreamforge.wordpress.com/2007/09/28/datenschaufleritis/#comment-3</guid>
		<description>In Bezug auf den Protokolloverhead darf zwischen HTTP und FTP bei solchen Datenmengen eigentlich kein großer Unterschied bestehen. Das ist ja in beiden Fällen einfach nur eine TCP-Strecke, auf die die Daten draufgepumpt werden. Der Application-Level-Overhead wäre da nur interessant, wenn du diese Datenmengen in Form von vielen kleinen Dateien überträgst; das scheint mir hier eher nicht der Fall zu sein. :)

Unter Umständen könnte hier tatsächlich etwas UDP-basiertes interessant sein. Im LAN ist ja per se der Paketverlust kein so großes Problem. Den eher pessimistischen TCP-Ansatz braucht man von daher nicht. Aber unter Hochlast könnten ACK-Traffic und andere Features von TCP durchaus auf den Durchsatz drücken. Mir fällt jetzt allerdings spontan kein UDP-basiertes Protokoll ein, dass man da benutzen könnte. Du bräuchtest eine Art modernisiertes TFTP.</description>
		<content:encoded><![CDATA[<p>In Bezug auf den Protokolloverhead darf zwischen HTTP und FTP bei solchen Datenmengen eigentlich kein großer Unterschied bestehen. Das ist ja in beiden Fällen einfach nur eine TCP-Strecke, auf die die Daten draufgepumpt werden. Der Application-Level-Overhead wäre da nur interessant, wenn du diese Datenmengen in Form von vielen kleinen Dateien überträgst; das scheint mir hier eher nicht der Fall zu sein. <img src='http://s.wordpress.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Unter Umständen könnte hier tatsächlich etwas UDP-basiertes interessant sein. Im LAN ist ja per se der Paketverlust kein so großes Problem. Den eher pessimistischen TCP-Ansatz braucht man von daher nicht. Aber unter Hochlast könnten ACK-Traffic und andere Features von TCP durchaus auf den Durchsatz drücken. Mir fällt jetzt allerdings spontan kein UDP-basiertes Protokoll ein, dass man da benutzen könnte. Du bräuchtest eine Art modernisiertes TFTP.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
