# FTP vs HTTP



## CyD (24. Mrz 2008)

Hi Leutz. 

Also, ich hab vor kurzen ein Programm geschrieben um Dateien/Ordner von Computer zu Computer zu übertragen. 
Das Programm läuft (bisher) ohne Probleme. Allerdings hab ich bei der letzten LAN bemerkt, das 
die meisten keine Lust haben extra noch ein Programm zu installieren/kopieren um einige Daten zu übertragen.

Dann hat mich ein Kumpel auf die Idee gebracht, die Daten mit Hilfe von FTP zu übertragen.
Einen FTP-Client hat im Grunde jeder, zB. einen Browser.

Ich hab mich dann ein bisschen auf dem Gebiet versucht schlau zu machen, bin aber dann auf HTTP gestoßen... 

Leider finde ich keine Seiten, die die beiden Protokolle, hinsichtlich der Datenübertragung, vergleichen.

Ich habe hier mal eine paar Stichpunkte, mit Funktionen, die mein eingenes Protokoll kann. Ich würde gerne wissen, in wie weit FTP oder HTTP solche Sachen unterstützen.

*a) Passwortschutz:*
AFAIK arbeitet HTTP vollkommen ohne Passwörter. Bei FTP muss man sich immer einloggen und jeder User hat seine Berechtigungen für Ordner.

Wäre es auch möglich nur bestimmte Ordner mit einem Passwort zu versehen? Ohne jetzt User oder Gruppen mit diesem Ordner zu verknüpfen?

*b) Übertragung Pausieren:*
IMO kann sowohl HTTP als auch FTP die Übertragung pausieren. 

*c) Übertragung neu beginnen:*
Gibt es mit HTTP oder FTP eine Möglichkeit eine Datei zu übertragen, von der bereits ein Teil übertragen worden ist, ohne die Datei von Beginn an noch einmal neu übertragen zu müssen?

*d) Ordner mit einem Kommentar versehen:*
Ich hab irgendwo gelesen, das man auch in FTP ordner mit einem Kommentar versehen kann. So weit ich weis in Form einer Textdatei in dem betreffendem Ordner. Vielleicht habt ihr genauere Informationen.

*e) Mehrere Downloads parallel:*
Bei beiden Protokollen ist eine Übertragung von mehreren Dateien gleichzeitig möglich.


Der Vorteil von HTTP wäre natürlich noch die hübschere Darstellung der Daten mit Hilfe von HTML. Allerdings lege ich darauf keinen Wert, immerhin kann man ja auch auf eine FTP-URL verlinken.

Ich hoffe ihr könnt ein bisschen Licht in die Sache bringen.

gruß
CyD


----------



## Pappenheimer++ (25. Mrz 2008)

zu a): Doch, HTTP bietet auch einen Passwortschutz (wie z.b. den mit dem http-access file auf manchen Webservern). 

Zum Fortsetzen pausierter Downloads: Das scheint sich mit HTTP auch umsetzen zu lassen. Ich weiß zwar nicht genau wie, aber rapidshare bietet den Service und deren Downloads funktionieren über HTTP (unerwarteter Weise). Wie schwierig das umzusetzen sein wird, weiß ich nicht, aber irgendwie geht es


----------



## maki (25. Mrz 2008)

> zu a): Doch, HTTP bietet auch einen Passwortschutz (wie z.b. den mit dem http-access file auf manchen Webservern).


Natürlich unterstützt HTTP Authentifizierung, das sog. BASIC und das DIGEST:
http://www.ietf.org/rfc/rfc2617.txt

Ansonsten habe ich den Eindruck, hier wurde das Rad zum x-ten mal erfunden, wieviele Programme zum Dateitransfer braucht man eigentlich noch?
Gibt doch erst ein halbes dutzend Standards dafür und tausende Implementierungen...


----------



## tuxedo (25. Mrz 2008)

*Kopfschüttel*

Bis auf die Sache mit dem "Download wieder aufnehmen" können solche Dinge "moderne" Betriebssysteme von Haus aus (Stichwort: Windows Dateifreigabe, Samba unter Linux, ....).

Muss maki also voll und ganz zustimmen.


----------



## CyD (25. Mrz 2008)

maki hat gesagt.:
			
		

> Natürlich unterstützt HTTP Authentifizierung, das sog. BASIC und das DIGEST:
> http://www.ietf.org/rfc/rfc2617.txt



Danke! Ich glaube ich werd mich mal mit der Basic Authentication auseinandersetzten.



			
				alex0801 hat gesagt.:
			
		

> *Kopfschüttel*
> 
> Bis auf die Sache mit dem "Download wieder aufnehmen" können solche Dinge "moderne" Betriebssysteme von Haus aus (Stichwort: Windows Dateifreigabe, Samba unter Linux, ....).
> 
> Muss maki also voll und ganz zustimmen.



Na gut, das ist euere persönliche Entscheidung, ob ihr so ein Programm braucht oder nicht.

Natürlich könnt ich bereits bestehende ServerProgramme nutzen, aber Lernen tu ich dabei nicht viel. 

@alex0801: Warum hast du denn SIMON entwickelt, obwohl RMI bereits da war?

Meiner Meinung nach schaden Alternativen nicht! Im Gegenteil: Sie machen einen Wettbewerb erst möglich.
Ich könnt mein Programm auch so lassen, wie es momentan ist. Allerdings würde ich mit einem bekannten Protokoll eine höhere Kompatiblität erreichen.

Alles was ich wissen möchte ist welche der beiden Protokolle diese Aufgabe am Besten erfüllen kann.


----------



## tuxedo (25. Mrz 2008)

CyD hat gesagt.:
			
		

> @alex0801: Warum hast du denn SIMON entwickelt, obwohl RMI bereits da war?
> 
> Meiner Meinung nach schaden Alternativen nicht! Im Gegenteil: Sie machen einen Wettbewerb erst möglich.



SIMON hat eine komplett andere Zielgruppe als RMI. RMI wird häufig in UNternehmen, auch in Kombination mit JBOss und Co. eingesetzt.

Simon ziel auf Client-Server-Systeme ab, welche mit dem Internet problemlos zurecht kommen müssen. RMI ist hier gänzlich ungeeignet wenn man den Funktionsumfang auch nur zu einem Bruchteil ausschöpfen will. 

Ich stehe nicht im "Wettbewerb" mit RMI. Genausowenig wie ein 7er BMW nicht mit einem Fiat 500 im Wettbewerb steht. Die Käuferschicht/Nutzerschicht ist eine ganz andere. 



> Alles was ich wissen möchte ist welche der beiden Protokolle diese Aufgabe am Besten erfüllen kann.


von den beiden von dir genannten: FTP

Aber wenn du einen "Augenblick" über das nachgedacht hättest was ich vorgeschlagen hab, so wäre dir CIFS als Protokoll aufgefallen. Im Vergleich zu einem Webbrowser als Client, hat die Windows-Dateifreigabe doch x-mal mehr Vorteile. FTP ist da, für diesen Anwendungszweck, in meinen Augen, eindeutig unterlegen. 

- Alex


----------



## CyD (25. Mrz 2008)

Achso... der Unterschied zwischen RMI und Simon war mir jetzt nicht ganz klar. Sorry.


BTT: 
Ich denke ich werde dann doch FTP verwenden.

Weil es (meiner Meinung nach) leichter in mein bisheriges Programm integriert werden kann als SMB bzw CIFS.
Naja... mal sehen wie es sich entwickelt...


----------



## HoaX (25. Mrz 2008)

einen cifs server würde ich auch niemals in eine eigenen software einbauen. weil man sicherlich jeden benutzer damit überfordert wenn er vorher den entsprechenden windowsdienst beenden muss damit die ports frei werden du man verwenden _muss_

wenn es nur ums dateien hin und her scheiben geht würde ich auch zu ftp neigen.


----------



## tuxedo (26. Mrz 2008)

Ihr stellt euch an ...

@CyD

CIFS in ein eigenes Java-Programm einbauen halte ich aucn nicht für sinnvoll. Wieso auch... Windows kann da sschon von Haus aus. Aber es wäre dennoch machbar. Schließlich gibts für CIFS eine passende Lib für Java.

Aber mal davon abgesehen:

Woher kommt die intention ein Programm zu basteln, das mehr oder weniger genau das macht was jedes aktuelle Betriebssystem von Haus aus kann und schon mehr oder weniger optimal aufbereitet dem Nutzer anbietet?
Das ist ja wie wenn ich einen Autotransporter habe und mir dann noch ein Auto kaufe, es auf den Hänger stelle, nur um meinen Beifahrer von A nach B zu kutschieren während er im Auto aufm Autotransporter sitzt.
Ist ja nicht so dass der Autotransporter nicht auch nen Beifahrersitz hat...

Naja, jedem das seine.

- Alex


----------



## HoaX (26. Mrz 2008)

das ist reines marketing  
man kann dann werben dass man komfortabel in einer s-klasse coufiert wird - in wirklichkeit ist es ein uralter ohne tüv vom schrottplatz. =)


----------



## tuxedo (26. Mrz 2008)

So kann man's auch sehen. Ich seh da auch nichtmal einen Lerneffekt wenn man was bestehenden, funktionierendes in einer eigenen Anwendung nochmal umverpackt und seinen Namen drauf schreibt. Okay, vielleicht doch einen ... Nämlich den, dass man die Zeit dann doch besser in was anständiges investiert ;-)

Aber nun gut, wir wollen dem Threadstarter ja nicht alles ausreden oder unsere Meinung aufdrängen ;-)


----------

