  |
|
|
 |
 Instant Messenger |
Antiheld 
Spagetti-Monster (Moderator)
Dabei seit: 07.08.2001
Beiträge: 755
Herkunft: Duisburg
 |
|
| Instant Messenger |
|
Hallo Leute,
-
In der 13ten Klasse haben wir die Aufgabe eine Projekt im Rahmen von Datenverarebitung oder Mathematik zu bewältigen. Das Thema des Projektes wählen wir selbst. Ich dachte mir zusamen mit 2 Gruppenmitgliedern einen Instand Messanger zu programieren in C oder C++. Da wir an Donnerstag eine Projektdefinition abliefern müssen, wollte ich mir mal über die Ausmaße bewust werden:
- Ein Server
- Client
- Simple Datenbank für die Benutzerkartei
- Socket Programierung
Wir haben durchschnittliche Programier Kenntnisse, halt das was wir bis jetzt im Unterricht hatten. Hat jemand schon mal sowas gemacht bzw dazu Gedanken gemacht? Abgabe ist im November.
Was denkt ihr?
Cu
Anti
__________________
Of course, like every other man of intelligence and education I do believe in organic evolution. It surprises me that at this late date such questions should be raised.
-Woodrow Wilson, 1922 >>
|
|
18.05.2005 09:15 |
|
|
Cpt.Miller
BlackBoarder
Dabei seit: 14.08.2003
Beiträge: 644
Herkunft: Stuttgart
|
|
Im Prinzip hast du schon alles gesagt, nur ist es ohne richtige Planung teilweise sehr schwer sowas zu realisieren. Interessant währen übrigens andere Informationen, wie z.B. die Plattform auf der das laufen soll, welche Technologien dürft ihr verwendet etc...
Wie gesagt, du hast eigentlich schon alles gesagt, nur zum Server würde mir noch was einfallen:
Wie wollt ihr die Nachrichtenübermittlung realisieren? Wollt ihr das der Server die Nachricht übermittelt, oder sollen die Clients untereinander extra Verbindungen aufbauen?
Das erstere würde wahrscheinlich mehr Rechenaufwand an die Serverapplikation erfordern, doch das andere könnte dann wiederrum Probleme beim User selbst geben, da vielleicht die Ports oder ähnliches nicht weitergeleitet werden (Router).
[Ich weiß allerdings nicht ob Sachen wie z.B. die Performance zur Laufzeit in die Berwertung eingehen, oder nicht.]
|
|
|
18.05.2005 09:44 |
|
|
CDW
eine Simulation
Dabei seit: 12.10.2002
Beiträge: 1.329
Herkunft: CreateRemoteThread
|
|
man sollte es nicht unteschätzen - es kann schnell immer und immer mehr werden. Z.B wenn man schon bei der Benutzeridentifizierung anfängt: sollen Name und Passwort im klartext übertragen werden? Wenn nicht was nimmt man dann? (open SSL -Projekt bietet dazu gute Libs).Wie realisiere ich die Benutzerverwaltung usw. ?
Wie sollen meine Clients kommunizieren (also Application Protokol ala HTTP/IRC) ? Wie realisiert man den Server? Als Apache mit PHP oder eben ein eigenes Programm?
Siehe auch Punkte von Cpt.Miller.
Ich hab mir mal dazu Gedanken gemacht 
, werde mal abends was dazu posten.
@Antiheld:
| Zitat: |
| Wir haben durchschnittliche Programier Kenntnisse, halt das was wir bis jetzt im Unterricht hatten |
wie durchschnittlich
? Also z.B schon erfahrungen mit Sockets, Datenbanken allgemein?
Und wie groß muss das Projekt werden? Wenn es paar hundert bis paar tausend User verwalten soll kann man anders vorgehen und sich viel Zeit sparen. Wenn man allerdings aus Prinzip schon eine Anwendung schreiben will die sehr viele User verwalten (können) soll - hm, da muss man sich viel mehr gedanken machen.
|
|
|
18.05.2005 12:37 |
|
|
Antiheld
Spagetti-Monster (Moderator)
Dabei seit: 07.08.2001
Beiträge: 755
Herkunft: Duisburg
Themenstarter 
|
|
Danke schonmal für die Antworten. Ich hatte mir für die Datenübertragung vorgestellt das der Server die Nachrichten übermittelt, der Rechenaufwand spielt im Grunde aber auch keine große Rolle dabei. Ich denke mal wir sind schon ganz zufrieden wenn wir 2-3 User zusammen haben die das Programm, zwecks des Projektes nutzen. Es soll wirklich nichts überdimensionales darstellen, sonder halt einfach nur einen simplen IM. Die Übertragung der Daten wie Namen und Passowort kann im Klartext übertragen werden, vielleicht machen wir das noch als zusatz, je nach Zeit.
Cu
Anti
__________________
Of course, like every other man of intelligence and education I do believe in organic evolution. It surprises me that at this late date such questions should be raised.
-Woodrow Wilson, 1922 >>
|
|
|
18.05.2005 14:19 |
|
|
CDW
eine Simulation
Dabei seit: 12.10.2002
Beiträge: 1.329
Herkunft: CreateRemoteThread
|
|
Ich hab mal im "offline modus" was zusammengeschrieben. Allerdings hab ich
nicht die Möglichkeit alles über den Server abzuwickeln berücksichtigt:
Mir fallen da zwei grobe Herangehnsweisen ein:
1.Kommunikation läuft komplett
über den Server. Vorteil: einfacher umzusetzen. Nachteil: Server wird sehr belastet, schon bei relativ wenigen Usern:
Traffic,Rechenzeit.
2.der Server dient nur als Übermittler: nimmt und verwaltet Anmeldungen und
übermittelt bei Anfrage die Userdaten (IP), die restliche Kommunikation wickeln
die Clients unter sich ab. IMHO ist die 2 Möglichkeit besser. Dazu fallen mir
ein paar Punkte ein (die sind eigenlich für die 2te möglichkeit gedacht, sollten
aber auch in der 1 nicht verkehrt sein):
1.Modularität:
Es versteht sich ja von selbst dass man modular programmiert
da ich jedoch C++ oder C nicht wirklich mächtig bin will ich nicht darauf eingehn.
Man könnte so einen IM in mehrere Module zerplittern, so dass jedes Modul
austauschbar wäre ohne dass die restlichen komponente angepasst werden müssten.
Außerdem kann man auch im nachhinein einzelne Module erweitern und anpassen und
auch besser austesten.
Grobe Einteilung wäre z. Servermodul, Clientmodul, GUI-Modul.
Man sollte hier erstmal rudimentäre Funktionen vor Augen haben die
umgesetzt werden müssen, denn je mehr man nachdenkt desto mehr fällt einem ein.
Server:
- ermöglicht die Erstanmeldung bei dem IM Dienst
- bei der "normalen" Anmeldung aktualisiert die Datenbank (USERNR xxx hat IP xyz)
- übermittelt bei Anfrage die IP einer USer-Nummer
mehr nicht. Man kann hier natürlich noch viele sinnvolle Erweiterungen
einbauen wie z.B dass bevor jemand "geadded" wird er vorher bestätigen
möchte. Dass in der Datenbank vermekrt wird welche User welche anderen
als "Buddys" haben und dass nur an diese die IPs übermittelt werden und die anderen
müssen vorher nach einer Bestätigung fragen.
Sinnvoll wäre auch mehrfache Anmeldungen zu sperren (in dem z.B die aktuelle IP
mit den von anderen Usern verglichen wird, hier gibts natürlich wieder das
"Netzwerk hinter einem Router" Problem).Und vieles mehr.
Client: der Client sollte als Backendanwendung laufen, sprich keine GUI.
um die GUI-Darstellung kümmert sich das GUI modul. Vorteil ist die bessere
Übersicht im Code und dass man mit wenig Aufwand den Client auf viele Plattformen portieren kann
und die entsprechnde GUI erst da hinzufügen.
- muss beim Start oder nach einer Verbindungsunterbrechung die
neue IP an den Server übermitteln
- muss zu einer Usernr. gerhörende IP beim Sever abfragen können
- muss User verwalten, ob in Liste oder Baum oder sonstwo
Die rudimentären Daten wären: UserNr, Nic, IP, User_is_online.
- muss auf Verbindungsversuche reagieren können (also z.B entgegennehmen oder ignorieren
)
so dass man Chatten kann. Hier gibt es noch mehrere Optionen:
soll man den Usern ermöglichen eine Art Chatrooms aufmachen zu lassen oder
nur 1:1 Chats? IMHO ist mit ein wenig Aufwand auch eine Chatroom version mögich.
Wie man es ohne GUI realisiert? Konsole. Ein und ausgabe, das GUI-Modul
soll das Clientmodul starten und über Pipes befehle geben.
- Schön ist auch eine ignorierfunktion gegen manche User
- wenn der Client beendet wird sollte er den Server benachrichtigen.
Verbindungsmanagmentvorschlag siehe unten.
GUI: stellt alle Möglichkeiten grafisch dar.
Kommunikation:
HTTP,FTP usw machen es schon vor: Steuercodes sind sehr nützlich.
IMHO kann man damit vieles bequemer und einfacher machen:
Beispiel:
1XX Fehlercodes vom Server
2XX Server->Client Steuercodes
3xx Client->Server Steuercodes
4xx Server->Client information
5xx Client->Client kommnikation
6xx Client->client Fehlercodes
Man hat dadurch mehrere Vorteile: z.B kann man den Client zu einem Fehlercode
eine Meldung ausgeben lassen. Und man kann dadurch die ganze kommikation schön
logisch trennen und dadurch auch alles durch einen Port "schleusen".
Beispiel: der Client lauscht an Port 2000
Erste Nachricht (kommt vom Server): 206 User XXX/NR YZ möchte Sie adden
Der Client kann jetzt dementsprechend reagieren und z.B den User fragen.
Zweite Nachricht (von einem andern Client) 402(Text) "Hey Alter wie gehts"
Der Client gibt es in einem Chatfenster aus.
Hier müsst ihr gut überlegen, je besser man den Kommunikationsprotokol plant desto
einfacher hat man es später.
Programmiertechnisch gesehen sollte hier keine Schwirigkeit sein: wenn man was
sendet dann sind z.B die ersten 3 Stellen auf jedenfall ein Steuercode.
Man muss diese auch nicht als ASCII abschicken.
Client: Umsetzung:
Um möglichst Probleme mit Routern zu vermeiden sollte man nur einen Port benutzen
so dass der User nicht tausende freischalten muss. Man kann auch
eventuell in der Datenbank vermerken auf welchem Port der User
seinen Client betreibt und es den anderen Übermitteln (wie man sieht fällt einem
immer mehr ein
)
Wenn der Client sich zum Server oder anderen clients verbindet kümmert sich
i.d.R. das Os um den lokalen Port (zumindest kenne ich das nur so).
Da man ja aber die Verbindung selber initiirt sollte es kein Problem routerlicher
seits sein.
Pro Verbindung wäre es am einfachsten jeweils einen neuen Thread aufzumachen.
Damit kann man ohne große Verrenkungen locker ein paar tausende User verwalten
Dann die Userverwaltung per Liste. eine Ignore-Liste wäre auch ok, von diesen
Usern wird dann keine Verbingung angenommen.
Beispiel: der Client lauscht am Port 2000
Verbindung kommt rein - akzeptieren, daten abfragen, reagieren.
Beispiel2: der User hat ein Chatroom aufgemacht:
ein anderer User sendet:404 (User an alle andern) "Hallo?".
Der Client schaut nur 404: muss ich weitersenden und
sendet an alle die in der Charoomliste stehen.
(natürlich nur Beispielsteuercodes
)
Server: Umsetzung:
Am einfachsten imho ein Webserver mit PHP/Perl und Datenbank.
Gerade in der aktuellen c't eine Anleitung dazu gefunden (erste schritte
mit PHP MySQL, Programmbeispiele).Der Client muss also nur
auf Port 80 verbinden und Anfrage abschicken: HTTP1.0 GET /User.php?301melde_mich_an_userid_XY
der User.php script verarbetet dann. Die einzige Hürde ist dass man
die Anfrage in HTTP richten muss (was aber imho nicht wesentlich stört).
Wenn man einen Anbieter hat der Executables erlaubt kann man natürlich auch einen
"normalen" Server draufsetzen. Der Clou bei dem Webserver und PHP ist, dass man
im PHP scritp den User-Agent abfragen kann und erfährt ob der User
per Browser oder per Client verbindung aufgenommen hat - dementsprechend
entweder eine HTML seite liefern oder nur Client-Steuercodes+Info.
Bei nicht allzuvielen User kann man auch auf die "richtige" Datenbank verzichten und
die User selber verwalten - z.B in einem Baum oder einer Liste.
Kommunikation: Beispielumsetzung:
angenommen jemand ist schon angemeldet und startet seinen Client.
Client an server: 301 bin der und der/USerid,Passworthash
Server an Client: entweder 401 alles ok, angemeldet, oder 10X Userid/Passwort nicht korrekt
Client an Benutzer (durch die GUI): Wir sind online! oder "Falsches Passwort blabla"
So, der User hat jetzt einige IDs von anderen Usern:
Client an Server: 302 "rück mal die (letzte bekannte)IP für User XYZ raus".
Server: 102 "gibts net" oder: 402. "xyz hat ip yxz sein Client läuft auf Prot ZX"
so geht der Client die Liste durch.
Jetzt, wo er die Liste hat, geht er die nochmal durch, aber etwas anders:
Client an Client(IP,Zielport) : 501, "UserXYZ hier, biste online?" (keiner
antwortet =>logische schlüssfolgerung
).Ansonten akzeptiert der Client die
Verbindung(z.B in einem Thread
) und Anwortet eben 502 "Ja, emfangsbreit" oder
601 "Usermessage: bin gerade auf dem Klo!"
Oder falls die UserID zu den ignorierenden gehört: 666 " zur hölle mit dir!"
und schließt sie wieder. Also die gesamte Liste.
Der Client übergibt dann die Liste an die GUI die es dann dem User präsentiert.
User möchte mit einem anderen Chatten: Client an Client:503 "Mag Chatten"
Client reagiert in dem er die Verbindung akzeptiert und den User
benachrichtigt/fragt und schickt: 509 "bereit zum chat" oder vielleicht auch:
510 "hab hier schon ein Chatroom, willste mitmachen?"
Der Client gibt hier entweder eine Nachricht aus, oder lässt die GUI ein neues
Chatfenser aufmachen.
Zur Verschlüsselung kann man z.B die OpenSSL libs benutzen. Da es
allerdings C/C++ Libs sind, kenne ich die nicht wirklich.
Und so weiter. Je mehr ich darüber nachdenke desto mehr fällt mir ein. 
Hoffe dass Du hier ein paar Ansatzpunkte findest.
|
|
|
18.05.2005 23:38 |
|
|
Antiheld
Spagetti-Monster (Moderator)
Dabei seit: 07.08.2001
Beiträge: 755
Herkunft: Duisburg
Themenstarter
|
|
Wow, danke CDW! Das wird uns echt viel Arbeit ersparen, auch wenn ich nicht glaube das wir einen 3 Stelligen Befehlscode brauchen 
Cu
Anti
__________________
Of course, like every other man of intelligence and education I do believe in organic evolution. It surprises me that at this late date such questions should be raised.
-Woodrow Wilson, 1922 >>
|
|
|
19.05.2005 19:39 |
|
|
|
|
|
|
|