Idee f�r den Mechanismus:
Anstatt das gesamte Archiv in den Arbeitsspeicher zu laden und dann zu verschicken,
wird ein Buffer fester Gr��e (bspw. 32kB oder 1MB) gef�llt und dessen Inhalt als einzelne Pakete verschickt.
Anders als bisher enthalten die Paketheader folgende Attribute: In wie viele Teile das Archiv zerteilt wird, der wie vielte Teil dieses Paket ist.

Ansatzpunkte:
  - neue Klasse von TransferDescription ableiten, die zus�tzliche Infos enth�lt
  - XMPPTransmitter.sendProjectArchive() ben�tigt neue (und alte) Senderoutine
  - XMPPTransmitter.receiveArchive() ben�tigt neue (und alte) Empfangsroutine
  
TransferDescription:
  - neuen Typ anlegen (Konstante)
  - in neuer Klasse 2 Attribute anlegen (+ Methoden entsprechend anpassen)
  
Mechanismus im Pseudecode:

XMPPTransmitter.sendProjectArchive():
	if(client hat neue Saros-Version):
		Buffer anlegen (Gr��e=Chunksize)
		
		while(noch Archivst�cke offen):
			Buffer f�llen
			neues TransferDescription-Objekt anlegen
			Bufferinhalt+Description versenden
	else: //altes Verfahren
		Buffer anlegen (Gr��e=Archivgr��e)
		Buffer f�llen (gesamte Datei)
		altes TransferDescription-Objekt anlegen
		Bufferinhalt+Description versenden

XMPPTransmitter.receiveArchive():
	Zwei PacketFilter samt SarosPacketCollector besorgen (um auf neu und alt zu lauschen) (n�tig??)
	abwarten, bis einer von beiden etwas empfangen hat
	
	if(Paket neuen Typs angekommen):
		Tempor�re Datei anlegen (RandomAccessFile)
		while(noch offene pakete):
			Paketinhalt an richtige Stelle in Datei schreiben
			auf neues Paket warten
		
		InputStream zum FileHandle zur�ckgeben
	else: //altes verfahren
		Paket annehmen
		Zugeh�rigen Stream zur�ckgeben


Offen:
	Wie behandeln wir den Monitor, der dem Fortschrittsbalken R�ckmeldung gibt?