Re: [Jfritz-devel] =?iso-8859-1?q?Netwerkf=E4hige_JFritz?=

[Marc W. <Mar...@gm...>]

je...@in... wrote:
> Hi,
> 
> Ich habe mich vor einer Woche entschieden, endlich mal an der Netzwerkversion
> von JFritz zu arbeiten. Dabei bin ich  (wie zu erwarten) auf einige
> Schwierigkeiten gestoßen und wollte diese Liste mal wieder für Kritik und
> Vorschläge für meine Ideen nutzen.
> 
> Also so weit bin ich mit Plänen schon: Weil die meisten diese Art wünschen,
> sollte JFritz auf Client/Server Basis funktionieren. Grundsätzlich wollte als
> erster Netzlast beim Server vermeiden (Die Listen können schon über 1MB Groß
> werden). Also habe ich vorgesehen, dass Daten zwischen Server und Client nur
> ausgetauscht werden, wenn neue Kontakte / Anrufe importiert werden oder
> bestehende verändert / gelöscht werden (wobei eine Veränderung eigentlich durch
> eine Enternun der alten Daten und einen Import der neuen Daten implementiert
> ist). Deswegen habe ich vorgesehen, dass bei
> jedem Import / Änderung / Entfernung CallList.java und TelephoneBook.java eine
> ProxyKlasse aufrufen, die dann eine Liste von verbundene Clients (Listener) hat
> und diese dann einzeln über ein Callback informiert. Eigentlich sollte diese
> ProxyKlasse jegliche Art von Netwerkclient / Server (LDAP usw.) verwalten
> können, in so fern dass diese Clients / Servers die Callback funktionieren
> unterstützen. 

Also ich würde würde es wohl mit Java Remote Method Invocation machen.
http://java.sun.com/docs/books/tutorial/rmi/index.html

Dann eine Klasse schreiben, in dem die entsprechenden Methoden drinn 
sind (add, update, remove). Dann brauchst Du die Daten auch nicht in XML 
oder csv umwandeln, sondern kannst direkt java Objekte verwenden.

> Ich habe mir die diverse Client/Server Frameworks für Java angeschaut und bin
> zu
> dem Schluss gekommen, dass diese zu kompliziert / nicht lohnenswert für unsere
> Ziele sind. Deswegen wird meine Implementierung auf gute alte TCP-Sockets
> basieren. Ein genaues Protokoll habe ich mir nicht fertig ausgedacht
> (Grundlegende Ideen habe ich schon), da ich mich in diesem Bereich nicht so gut
> auskenne, aber es muss an die o.g. Forderungen (Nur Daten beim Import /
> Verändern / Entternen). Ich habe gedacht, ich kann eine passive
> Clientverbindung implementieren, in der der Client fast ausschließlich auf
> Befehle vom Server wartet (ADD, UPDATE, REMOVE) aber noch die Möglich für eine
> Synch hat (GET).

Das ist in der Tat ein schwieriges Problem, eine Lösung wäre evtl. die 
update nachrichten mit Zeitstempeln zu markieren. Wenn sich dann ein 
Client beim Server anmeldet teilt er ihm mit, welches der letzte 
Timestamp ist, der letzten Updatenachricht, die er erhalten hat. Der 
Server schickt ihm dann alle Updatenachrichten, die einen größeren 
Timestamp haben. Somit muss der Client sich nur einmal anmelden und 
dannach nur noch zuhören.

 > Dies ist mir leider nicht sehr gut gelungen, weil ich mit dem
> Sychronisation nicht ganz klar gekommen bin, wie z.B. wann soll der Server auf
> Befehle vom Client aufpassen, wann soll der Client Befehle schreiben  usw...
> 
> Weil ich keine Sicherheitsbedenken in JFritz einbauen wollte, habe ich dann
> vorgehen, dass der JFritz-Server eine Liste von Kennungen / Passwörter (die
> später auch rechte und Filter haben können) haben wird. Somit wird jede
> eingehende Verbindung authentifiziert, bevor Daten ausgetauscht werden sollen.

http://java.sun.com/j2se/1.5.0/docs/guide/rmi/relnotes.html

Damit ist soweit ich es interpretiere auch eine Authentifizierung 
möglich. Aber ich habe keinen Überblick, wieviel Arbeit das ist. Aber 
lernen tut man dabei bestimmt was :D

> Der JFritz-Server sollte aus einem Listener-Thread, der auf die Verbindungen
> wartet (durch eine MaxVerbindungen Parameter beschränkt), und für jeden Client
> einen eigenen "Worker" Thread, damit die Arbeit möglichst verteilt ist. 

Gute Idee.


> Daten
> für die Anrufliste und TelephoneBook werden im Protokol über CSV ausgetauscht,
> weil das kompakter als XML ist.
> 
> Für Vorschläge / Kritik wäre ich sehr Dankbar, vor allem weil ich diese Arbeit
> angefangen habe, weil ich etwas daraus lernen will.

So das sind mal meine Vorschläge, ich hoffe sie sind hilfreich.

Gruß Marc