Use-Cases

[Robert Kummer]

Welche Anwendungsfälle brauchen wir so im Storage-Grid?

UC1. Nutzer will eine Datei in das Grid speichern
UC2. Nutzer lädt Datei zu Node hoch
UC3. Node verschlüsselt hochgeladene Datei auf Wunsch vom Nutzer
UC4. Node verteilt hochgeladene Datei in X gleichen Teilen an
verschiedene Nodes
UC5. Node bringt verfügbare Nodes in Erfahrung
UC6. Node meldet sich als verfügbar bei Master-Node
UC7. Node meldet sich bei Master-Node ab (Daemon wird gestoppt)
UC8. Node kann Liste aller eigens verwalteten Dateien ausgeben
UC9. Node kann Liste aller Dateiteile für einen Nutzer ausgeben
UC10. Nutzer kann seine Datei aus dem Grid laden
UC11. Nutzer kann eigene Datei anderen Nutzern freigeben (Nutzer-ID
könnte E-Mail sein) (V2 Protokoll)
UC12. Node kann eigene Daten bekanntgeben (IP, Port, Geolocation,
Freier Speicher, Speicher total, Anzahl Nutzer, Anzahl Dateiteile,
Läuft seit) (Servicefunktion)

Offene Fragen:
Kann man seine Dateien auch von einem Node herunterladen, der nicht
der Node des Uploads ist? Sollte eigentlich gehen, da vielleicht der
lokal näherliegende Node einfach schneller liefern kann.

[Raphael Niederer]

Ich hab hier eine kleine Korrektur, die aus meiner Sicht noch wichtig
ist:

UC2/UC3: Ich persönlich würde nicht keine unverschlüsselte Datei an
einen Node senden. Zudem weiss man ja nicht, ob derjenige, der den
Node programmiert hat "böse" Absichten hat... Die Verschlüsselung
gehört in den Client.

Datei hochladen:
UC1: Nutzer will eine Datei in das Grid speichern
UC2: Datei wird in x gleiche Teile aufgesplittet und verschlüsselt
UC3: Client fragt beim Master-Node nach den verfügbaren Nodes
UC4: Der Client sendet seine verschlüsselten Daten-Teile an x
beliebige Nodes (an wie viele Nodes man seine Daten senden möchte, ist
jedem selber überlassen)
UC5: Der Client speichert bei sich ab, wohin er die Daten versendet
hat

Somit braucht der Master-Node nur als "DNS-Server" zu fungieren...

[Sascha Ohms]

Ich würde dennoch eine Verschlüsselung vom Node erzwingen. Auch wenn dieser evtl. nur vorgibt dies getan zu haben. Es geht mir darum, dass User, die einen Client schreiben wollen von Verschlüsselung evtl. weniger Ahnung haben und es dann daran scheitert einen Client zu schreiben.

Sascha

[Oliver Tempel]

Ich denke auch das die Verschl�sselung eine Grundvorraussetzung ist und
der Client nur Daten akzeptiert die verschl�sselt sind.

Am 24.08.2011 08:00, schrieb Sascha Ohms:
> Ich w�rde dennoch eine Verschl�sselung vom Node erzwingen. Auch wenn dieser evtl. nur vorgibt dies getan zu haben. Es geht mir darum, dass User, die einen Client schreiben wollen von Verschl�sselung evtl. weniger Ahnung haben und es dann daran scheitert einen Client zu schreiben.

>
> Sascha
>
> On 24.08.2011, at 07:57, Raphael Niederer wrote:
>
>> Ich hab hier eine kleine Korrektur, die aus meiner Sicht noch wichtig
>> ist:
>>

>> UC2/UC3: Ich pers�nlich w�rde nicht keine unverschl�sselte Datei an

>> einen Node senden. Zudem weiss man ja nicht, ob derjenige, der den

>> Node programmiert hat "b�se" Absichten hat... Die Verschl�sselung
>> geh�rt in den Client.

>>
>> Datei hochladen:
>> UC1: Nutzer will eine Datei in das Grid speichern

>> UC2: Datei wird in x gleiche Teile aufgesplittet und verschl�sselt
>> UC3: Client fragt beim Master-Node nach den verf�gbaren Nodes
>> UC4: Der Client sendet seine verschl�sselten Daten-Teile an x
>> beliebige Nodes (an wie viele Nodes man seine Daten senden m�chte, ist
>> jedem selber �berlassen)

>> UC5: Der Client speichert bei sich ab, wohin er die Daten versendet
>> hat
>>
>> Somit braucht der Master-Node nur als "DNS-Server" zu fungieren...
>>
>>
>> On 23 Aug., 23:43, Robert Kummer<r...@ipunkt.biz> wrote:

>>> Welche Anwendungsf�lle brauchen wir so im Storage-Grid?

>>>
>>> UC1. Nutzer will eine Datei in das Grid speichern

>>> UC2. Nutzer l�dt Datei zu Node hoch
>>> UC3. Node verschl�sselt hochgeladene Datei auf Wunsch vom Nutzer

>>> UC4. Node verteilt hochgeladene Datei in X gleichen Teilen an
>>> verschiedene Nodes

>>> UC5. Node bringt verf�gbare Nodes in Erfahrung
>>> UC6. Node meldet sich als verf�gbar bei Master-Node

>>> UC7. Node meldet sich bei Master-Node ab (Daemon wird gestoppt)
>>> UC8. Node kann Liste aller eigens verwalteten Dateien ausgeben

>>> UC9. Node kann Liste aller Dateiteile f�r einen Nutzer ausgeben

>>> UC10. Nutzer kann seine Datei aus dem Grid laden
>>> UC11. Nutzer kann eigene Datei anderen Nutzern freigeben (Nutzer-ID

>>> k�nnte E-Mail sein) (V2 Protokoll)

>>> UC12. Node kann eigene Daten bekanntgeben (IP, Port, Geolocation,
>>> Freier Speicher, Speicher total, Anzahl Nutzer, Anzahl Dateiteile,

>>> L�uft seit) (Servicefunktion)

>>>
>>> Offene Fragen:
>>> Kann man seine Dateien auch von einem Node herunterladen, der nicht
>>> der Node des Uploads ist? Sollte eigentlich gehen, da vielleicht der

>>> lokal n�herliegende Node einfach schneller liefern kann.

--
------------------
Oliver Tempel
Gl�serstra�e 130
57074 Siegen

Tel.: 0271/55 130 91
Fax : 0271/55 130 92
E-Mail: in...@olivertempel.de
WEB : http://www.olivertempel.de

Diese E-Mail, einschlie�lich angeh�ngter Dateien, kann vertrauliche und/oder rechtlich gesch�tzte Informationen enthalten. Wenn Sie nicht der beabsichtigte Empf�nger sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und l�schen Sie diese E-Mail aus Ihrem System. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This message, including attachments, is intended for the above-mentioned addresses only. It may contain confidential information the review, dissemination or disclosure of which is strictly prohibited. Should you receive this message in error, please delete it and notify the sender to the e-mail address indicated above. This message, including attachments, is intended for the above-mentioned addresses only. It may contain confidential information the review, dissemination or disclosure of which is strictly prohibited. Should you receive this message in error, please delete it and notify the sender to the e-mail address indicated above.

[Markus]

Bitte nicht Client (der der die Daten hochladen will) mit Node (der wo
die Daten hin sollen) verwechseln, das verwirrt sonst. ;-)
Verschlüsselung auf dem Node ist wohl schon allein aus rechtlichen
Gründen notwendig. Wer garantier das der Client auch wirklich
verschlüsselt hat?
Aber wie schon im anderen "Thread" gefragt gibt es sinnvolle Use-Cases
dafür das ein Client etwas unverschlüsseltes speichern will? Ein von
allen lesbares Dokument oder sowas kA?

andere Use-Cases (geht wohl nur mit entsprechender Verifizierung, kann
man auch später implementieren):

Nutzer (Client) will Daten aus dem Grid löschen
Nutzer (Client) will Daten (zum Teil) im Grid aktualisieren (z.B.
irgendwelche Backups)