Hi Leute,
Eine Bekannte möchte mir 16 GB an RAW Dateien zum bearbeiten zukommen lassen. Aufgrund der Größe/uploadtime wäre es natürlich quälend es via we transfer, dropbox. etc zu probieren.
Gibt es eine Möglichkeit unsere 2 Mac's direkt zu verbinden um den Vorgang deutlich zu beschleunigen auch ohne fundiertes Netzwerk knowledge? Das einrichten bzw. nutzen einer afp:// verbindung wollte trotz emsigen probieren leider nicht funktionieren

Der Upload wird aber bei einer direkten Verbindung auch kein Stück schneller. Flaschenhals ist in der Regel der spärliche Upstream, den die Internet-Anbieter hierzulande bereit stellen, also der Internet-Zugang deiner Bekannten. Ich würde es daher wohl doch über einen Dienst wie Dropbox machen. Den Upload im Zweifel einfach über Nacht laufen lassen.

• BitTorrent Sync http://www.bittorrent.com/sync
• rsync, scp oder netcat via VPN oder direkter IP-Verbindung, wenn du dich mit der command line auskennst.

Je nach Upload-Geschwindigkeit, kann auch eine SD-Karte bzw. ein USB-Stick in der Post am schnellsten sein
Bei 1Mbit upload kann der transfer im Optimalfall zwischen 1-2 Tagen dauern.

Wie maniacintosh schon schrieb, der Flaschenhals ist vermutlich die Bandbreite des Upstream, kommt also darauf an, was er für einen Anschluß hat, bei 100mbit Glasfaser kann der Upstream durchaus brauchbar sein.

Eine Verbindung kann man über verschiedene Verfahren realisieren, dafür muss ggf. die Port-Weiterleitung im Router und die Firewall konfiguriert werden, auch ein dyndns-Adresse ist hilfreich und via Mac-Betriebsystem geht es ebenfalls. WebDav ist diesbezüglich auch zu empfehlen, eine direkte FTP-Verbindung sowieso.

Gleichwohl dürfte Dropbox der unkomplizierteste Weg sein wenn man das anders noch nie gemacht hat. Dropbox gilt zudem als vergleichsweise flink und es müssen nicht zwingend beide Rechner gleichzeitig am Netz hängen.

Mit einem NAS kann man so etwas ebenfalls komfortabel einrichten.

"Quer durchs Internet"? Nein. Und das schon aus Prinzip nicht und schon gar nicht mit "afp://".

AFP ist ein Protokoll, das entwickelt wurde, um das Bearbeiten eines zentralen Datenbestands durch viele verschiedene Leute parallel zu ermöglichen. D.h. es kommt einiges an sog. "Protokoll-Overhead" dazu: es würden prinzipiell schon mehr an Daten und noch dazu mehr Latenzkritisches übertragen. Die Verwendung von AFP in so einer Situation macht alles nur langsamer.

Das gilt kurioserweise ohne TCP/IP-Tuningmaßnahmen generell, wenn Du zwei eher schwachbrüstig angebundene Rechner "direkt" übers Internet verbinden willst. Denn das eine ist die sog. "Bandbreite" (bspw. "6000 Kbit/sek Downstream, 512 Kbit/sek Upstream" bei einem DSL-Anschluß), das andere sind Latenzen, die sog. "roundtrip time", die es braucht, bis ein Paket, das von A nach B gesendet wird, dann das "ich bin angekommen" an A zurückmeldet. Diese Latenzproblematik führt dann dazu, dass der eh schon dünne Upstream einer Verbindung (im Beispiel die 512 Kbit/sek) nicht mal ansatzweise ausgenutzt wird, weil ein Teil der Bandbreite dadurch brachliegt, dass der Sender immer erst auf die Empfangsquittung der Pakete warten muß.

Man kann an der Stelle jetzt händisch die TCP/IP-Settings auf beiden Seiten tunen, um ein paar Parameter zur individuellen Situation zwischen beiden Rechnern optimal anzupassen (etwas, an dem gerne auch Vollprofis scheitern, weil's eine fragile Geschichte ist und sinnigerweise durch Software besser erledigt werden kann: sog. "WAN-Beschleuniger", in der Regel ein sehr teurer Spaß) oder man kann bspw. mehrere TCP/IP-Verbindungen parallel aufsetzen, was die Problematik entschärft.

Oder man setzt einfach auf "Gegenstelle schnell angebunden" und "Software hat schon selbst paar Optimierungen an Bord": Dann landest Du wieder bei Dropbox und Konsorten. Dort sollte der Upload schneller vonstatten gehen als bei einer "Direktverbindung" ohne TCP/IP-Tuning, v.a. wenn die nicht mehrere TCP/IP-Verbindungen parallel etablieren sollte, um die Roundtrip-Time-Problematik zu entschärfen. Wahrscheinlich ist das Ganze inkl. anschl. Download-Zeit über einen schnellen zentralen Server flotter abgewickelt als direkt.

Wieder eines der Beispiele, wo das, was man "erwarten sollte" (direkt muß doch schneller gehen) gar nicht so logisch ist, wenn man sich den Kram mal im Detail anschaut. Und ein "low tech"-Ansatz evtl. der Beste ist (SD-Card in Pappschablone -- zwengs Förderband-Fähigkeit -- in Umschlag). 16 GByte kaum mehr komprimierbare Daten über die beispielhaften 512 Kbit/sek prügeln zu wollen, dauert mindestens 3,5 Tage. Viel Spaß

...dann könnte man die Dateien auch auf eine XD-Card kopieren und diese als Brief versenden

muchas gracias für die fundierte Resonanz!
Innerhalb DE wäre die Post auch meine 1te Wahl.

TCP/IP-Tuning oder ftp. Verbindungen zu konfigurieren würde uns 2 Dau's vor eine Riesen Hürde stellen

Die Bit torrent Sync Variante hört sich interessant/ relativ einfach zu bedienen an. Kann man grob sagen welchen Geschwindigkeits-vorteil gegenüber dropbox und Konsorten ich bei 1000 Kbit/sek Upstream habe?

BitTorrent Sync Vorteil: Keine Begrenzung der Datengröße. Nachteil: Tendenziell langsamer als Dropbox. Rechne mal mit ¼-½ der nominalen Bandbreite als Maximum.

Ist doch ganz einfach…auf einen Server legen kannst eh nicht schneller als dein Upstream ist…das machst einfach über Nacht, auf irgendeinen solideren Filehoster, schickst dem Adressat den Link zum laden und fertig.

der kann in der Regel 10 bis 25 mal schneller laden als du streamen und es gibt keinen bis kaum einen Server im Netz der nur annähernd so langsam lädt wie du streamst.

Tatsächlich hab ich das mal ausprobiert, USB Stick an Flitzibox/Router/weitergeleitet, bzw. dmz mit DaynDNS.Org und link geschickt…

Ewig gedauert und der miese Stick an der Flitzibox ist brutal heiß geworden.

Und ja,
rechne mal:

20 Megabit bringen 2 Megabyte in der Sekunde…deine USB 2 Platte oder Stick, um die 6 bis 38 Megabyte die Sekunde auf den Rechner/Platte,
1 Gigabyte gleich 1024 Megabyte,

grob überschlagen kannst du in 2,27 Stunden 16 GB laden bei 20 Megabit und bei einem üblicheren Upload von einem Megabit eben 20 mal so lang, also jenseits der 24 Stunden, bis du es nur hochgeladen hast

da kannst dir natürlich ernsthaft überlegen,
a) in eine Internetcafe mit gutem Upstream und freundlichen bis kompetenteren Personal zu gehen
oder
b) bei Postsendungen über Nacht in Deutschland es schlicht per Brief zu schicken

Disclaimer: Alles Ungepakt/Unkompremiert gerechnet

Per Kabel direkt, notfalls Wlan Kabel von Siemens…oder sonstigem heftigeren Apparaturen auf 300 meter Abstand geht natürlich schon auch…aber mitunter Teuer

Wenn Du Euch als Dau's bezeichnest, ist Post oder Dropbox das einfachste.
Im letzteren Fall sind die einzelnen Dateien, wenn sie erst einmal angekommen, auch sofort einsatzbereit, also den Ordnerinhalt auf die Dropbox schieben und nicht ein einziges 16GB großes ZIP.

Da kannste mit der Bearbeitung schon einmal anfangen, das dauert je ebenfalls seine Zeit und die übrigen Files wachsen so langsam rüber.

Zudem kann man dabei leicht abschätzen, wie lande der gesamte Transfer braucht und ggf. ergänzend eine Postsendung fertig machen.

Egal mit welchem Tool auf der Empfänger-Seite runtergeladen wird, das Entscheidende ist der Upload auf der Absender-Seite und der kann nun mal nur das was er kann.

Zum Glück ist das TCP-interne Gedöns schon soweit funktiontüchtig das das Schrauben drehen von ganz allein klappt. Du kannst auch gern an den Clients was rumstellen, aber das wird nicht viel bringen, wenn du dazwischen Systeme hast, die wieder in deine TCP-Verbindung eingreifen und die Kontrolle darüber übernehmen. Im Heimanwenderbereich ist da leider nicht viel möglich um einzugreifen.

Aber im Großen und Ganzen würde ich auch die Post-Methode empfehlen, die sollte fast schneller sein.

"Bittorrent Sync“ App

Deshalb ja auch die Einschränkung auf die nominale (Upload-)Bandbreite.

Fazit: Das nächste mal via Einwurfeinschreiben!
Meine Bekannte hat die Files einem Studi mitgegeben der es an seiner Uni upgeloadet hat wobei das auch nicht unbedingt sehr rasch ging

Bittorrent Sync hab ich mit einer 1 GB Test Datei einmal ausprobiert / Von der performance nimmt sich das nichts aber wenn es mal etwas mehr als die übliche "free" Kapazität der Platzhirsche sein soll & Zeit keine Rolle spielt ist das eine bequeme Variante..

Ach bzgl. FTP Verbindung, diese wäre doch dann auch nur so fix wie mein maximal zur Verfügung stehender upload oder?

Wie gesagt in der Regel ist der Upstream der limitierende Faktor, da dieser in der Regel deutlich niedriger ist als der Downstream der Gegenstelle. Dies gilt natürlich auch bei einer direkten FTP-Verbindung. Mehr als der Upstream her gibt, kann man an einem Internet-Anschluss niemals ins Netz schieben.

Es gibt jedoch auch Fälle, in denen ist das Hindernis an anderer Stelle. Wenn ich z.B. jemandem mit DSL 6000 Daten schicken würde, wäre der Downstream auf der anderen Seite der limitierende Faktor, da ich mit VDSL50 immerhin mit ca. 10.000 kBit/s senden könnte, aber die andere Seite kann da nur mit 6.000 kBit/s empfangen. Es gibt aber auch Fälle, da liegt "die Bremse" im Internet, weil die Daten über ein überlasteten Router oder ein ausgelastetes Seekabel müssen oder ähnliches. Dann gibt es auch noch Internet über UMTS/HSDPA/LTE, hier kann schon ein weiterer Nutzer in der gleichen Funkzelle die theoretischen Datenraten zunichte machen. Und dann gibt es auch noch bei manchen Providern Drosseln die nach gewissen Datenmengen greifen. (KDG für P2P, generell Internet über HSDPA/LTE, die neuen o2-Tarife oder eben auch der kleinste DSL-Tarif bei 1&1)

Und dann gibt es noch den einen wahnsinnig spannenden aber gerne übersehenen Faktor der sog. "Paketumlaufzeit" . Ein TCP/IP-Datenpaket, das auf die Reise geschickt wird, muß vom Empfänger bestätigt werden und dann erst kommt das nächste Paket, mal sehr stark vereinfacht geschrieben.

Was bedeutet das, wenn man wissen will, ob es schlauer ist, über einen zentralen Server zu gehen oder eine "Direktverbindung" zu etablieren? Dass eben nicht nur die Bandbreite des "Upstream" eine Rolle spielt sondern leider auch die Latenzen, die die Pakete vom Sender zum Empfänger und zurück brauchen (für die Paketquittung).

Ein drastisches Beispiel. Mein Mac eben per WLAN hinter einer Fritzbox hinter einem VDSL-Anschluß, Upstream immer identisch (10 MBit/sek rum), Messung des "reinen Durchsatz" per iperf:

Gegenstelle A (Server irgendwo in einem RZ in D per Gbit angebunden): 9.32 Mbits/sec

Gegenstelle B (Server am anderen Ende der Welt mit 24 Mbit/sek angebunden): 7.12 Mbits/sec

Über 2 MBit/sek Durchsatz weniger obwohl mein Upstream natürlich in beiden Fällen gleich "breit" und die Anbindung der jeweiligen Gegenstellen immer ein Vielfaches davon war. Aber die Werte weichen dermaßen drastisch ab. Warum? Wegen der bösen Latenzen, die im Falle von B natürlich häßlich hoch sind, weil keinerlei WAN-Beschleuniger oder manuelle TCP/IP-Stack-Tuning-Maßnahmen ergriffen wurden. Simpelst per "ping" gemessen:

A: round-trip min/avg/max/stddev = 24.545/25.697/27.778/1.245 ms

B: round-trip min/avg/max/stddev = 266.750/284.975/362.280/30.958 ms

D.h. die 10-12-fach höheren Werte in Millisekunden beschneiden mir effektiv den "Upload" schon mal um mehr als 20%. Wenn der Upstream "dünner" ausfällt, kann sich das noch drastischer auswirken. Da der Threadersteller von "grenzüberschreitendem" Traffic gesprochen hat und falls die "Gegenstelle" mit hohen Latenzen angebunden ist und evtl. noch Paketfragmentierung zum Tragen kommt (kann man auch per ping mittels "-D" und "-s" messen), dann kommt man schnell in die komische Situation, dass über einen "Upstream" von bspw. 512 KBit/sek nur traurige 300 Kbit/sek zu einer "weit entfernten" Gegenstelle gehen während der selbe "Upstream" hin zu einem "nahen" Server 460-480 Kbit/sek hergibt. Bandbreite ist das eine, Latenzen sind das andere.

Und das Ganze wird ganz schnell nochmal 'ne ganz andere Nummer, wenn irgendwas bzgl. Leitungsqualität auf einer der Seiten reinfunkt. Treten da nämlich Fehler auf, kommt's zu Retransmits einzelner Pakete und der Durchsatz bricht erst recht ein. Alles Sachen, die ein Netzwerk-Laie weder weiß noch "schnell mal eben" überhaupt feststellen kann. Und die bei "Direktverbindungen" viel viel häufiger ein Problem darstellen als wenn wenigstens eine der Gegenstellen ein gut angebundener Server ist.

Die alte Leier: Man muß im Detail hinschauen und sollte sich nicht von "einfachen Wahrheiten" (wie "der Upstream zählt" oder "direkt geht immer schneller") täuschen lassen.

Apropos iperf: Zum Testen ganz nett, wenn man 'ne aktuelle Fritzbox mit aktueller Firmware hat: Über http://fritz.box/support.lua kann man iperf auf der Box in verschiedenen Modi aktivieren, was bei Durchsatztests eine echte Hilfe sein kann.

@Thomas: Leider verwechselst Du etwas in Deinem Posting. Ich will das Thema aber nicht ausweiten. Der Towelie hat ja jetzt ne Möglichkeit gefunden.

Schade. Ich würd nämlich gerne dazulernen. Sonst wäre ich doch gar nicht hier

Weitere Möglichkeit: Installiere Hamachi (VPN-Netzwerk-Tool) auf beiden Geräten, dann kannst du direkt auf die vergebene IP Adresse zugreifen (via Finder, "Mit Server verbinden"). Habe ich so auch schon gemacht und läuft (Zwar nicht schnell aber angemessen). Geht auch zwischen Windows und Mac.

Nutz doch einfach das IPOAC Protokoll:
http://de.wikipedia.org/wiki/Internet_Protocol_over_Avian_Carriers
http://www.heise.de/netze/meldung/Brieftaube-so-schnell-wie-Breitband-Internet-755485.html
http://www.sueddeutsche.de/digital/brieftaube-gegen-internet-schnell-wie-der-winston-1.35745