Wer testet mein Programm?

[Thomebau]

Hi,
Ich habe um wieder einigermaßen fit in Delphi zu werden (das Abi in Informatik steht bald an) einen kleinen Chat Client für lokale Netzwerke geschrieben.
Wäre nett wenn ihr den mal testen könntet.

Läuft bisher nur unter Windows, zur Zeit habe ich noch Probleme mein Lazarus unter Ubuntu 11.10 zum kompilieren zu überreden...
Aber eine Linux Version wird folgen, dann sollte sogar plattformübergreifendes benutzen möglich sein.

Grundsätzlich wüsste ich gerne ob das Programm auf den diversen Windows Versionen die zur Zeit in Benutzung sind stabil läuft. Windows Xp, Vista und Windows 7. Ihr könnt natürlich mehrere Clients und Server auf ein und dem selben Rechner starten. Bei den Servern müsst ihr dazu nur einen anderen Port nehmen, sonst kommt es zu Komplikationen. Am sinnvollsten wäre aber natürlich die Benutzung in einem realen Netzwerk.

Den Download der "Thomebaus Netzerkchat.exe" findet ihr hier: www.philippthome.de/Uploads/Thomebaus%20Netzwerkchat.zip

Darin befindet sich kein Virus, das Programm stammt aus meiner Feder und liegt auf meinem Webspace.

Über eine möglichst rege Beteiligung würde ich mich freuen.

Im Gegenzug dazu dürft das Programm gerne behalten und nutzen wie ihr wollt. Nur verkaufen bitte nicht^^

Die Emailadresse für den Support ist noch nicht fertig eingerichtet, so lange könnt ihr euch noch hier an mich wenden.
Bevor ihr das Programm startet, einen Server auf macht und euch dann wundert lest bitte die "README.txt" , da steht alles wichtige drin.

Wenn jemand Lust hat mir das unter Linux zu kompilieren lasse ich euch gerne meine Lazarus Projektdaten zukommen
Das selbe gilt für den Umbau auf eine Variante die auch übers Internet funktioniert. Tipps sind immer willkommen.

 

[Toasterzizis]

Laufen tuts erst mal (XP SP3), Client und Server auf dem gleichen PC bzw Laptop...
Ein Verbesserungsvorschlag wäre Return/Enter zum senden benutzen zu können.

 

[bauernjunge]

Win7 Ult. x64 SP1 - läuft.

Ein paar Anregungen:
- Senden mit Shift+Return fände ich super. Vllt. als Option nur Return/Enter
- Eine Funktion den Chat nur zugelassenen Personen (Nutzername+Passwort) zugänglich zu machen
- Einzelnen Personen private Nachrichten zukommen lassen

Ich lad´s morgen mal auf 2-3 Rechner im LAN.

Letztes Jahr wollte ich ein Programm bei unseren Software-Jungs in Auftrag geben. Leider waren keine Resourcen vorhanden. Vielleicht finde ich meine Notizen von damals noch.....

mfg

 

[Thomebau]

Also das mit der Nutzeridentifizierung dürfte glaube ich ein bisschen hakelig werden, das ist auch der Grund dafür dass sich zur Zeit noch mehrere Nutzer mit den selben Nicknames anmelden können...

Das senden mit Enter ist in Arbeit, irgendwie hängt es noch irgendwo, der Druck auf Enter wird immer als zeilensprung interpretiert und nicht als Befehl. Sobald man im Feld drin ist mit dem Curser wird versucht einen zeilensprung zu machen, das konnte ich bisher noch nicht beheben.

Das Versenden an einzelne Clients (bzw. wird das dann sehr wahrscheinlich über die IP laufen) ist so etwas was ich mir auch noch vorgenommen habe.

Freut mich dass es mittlerweile wneigstens mal stabil läuft, hha hatte noch das Problem dass nach einer gewissen Zeit die Oberfläche verschwindet und erst bei einem Mouseover wieder auftaucht.

 

[u.mac]

IP ist dank DHCP nicht die beste Wahl - nimm zB. lieber den Hostnamen (den gibt's auch unter IPv6)

 

[alroar]

Warum nicht einfach per Multicast alles ins Netz streuen?

 

[Thomebau]

Uff, keine Ahnung wie ich das realisieren sollte...

Ich hab es ja mittlerweile schon da hin gehend umgebaut dass der Client die Nachricht an den Server sendet und dieser die Nachricht an alle Clients weiter schickt (auch an den Absender) un dann erst wird sie sichtbar ausgegeben auf dem sendenden und auf allen anderen Clients (und dem Server natürlich).

basiert also theoretisch auf dem Multicastprinzip, allerdings mit TCP Unterbau (wenn man das so nennen möchte, irgendwie gruselt es mich wenn ich das so lese).

Ich dachte auch schon daran den Chat per UDP zu realisieren, aber das habe ich dann doch lieber mal sein gelassen, das wäre zu aufwendig. Man bräuchte quasi UDP und TCP gleichzeitig. Sonst könnte man ja als Client nur empfangen. Und dann ist der Vorteil von UDP auch schon dahin wenn man eh TCP braucht zum senden. Bei TCP gehen zwar die Nachrichten alle nacheinander an die Clients raus, aber ist bei dem geringen Volumen kaum spürbar.

 

[alroar]

Verwechsel hier UDP und TCP nicht.

UDP: ungesichert, keinerlei Empfangsbestätigung, Resend, freie Portwahl (...), kein Connection aufbau notwendig, etc...
TCP: Gesicherte Paketvermittlung, Verbindungs wird vorher aufgebaut (Socket), Pakete werden quittiert / ggf. neu angefordert

Multicast: Pakete werden einfach ins Netz/Subnetz gefeuert, jeder der auf der Multicast Adresse lauscht, sieht diese

 

[Thomebau]

ich hab udp und tcp nicht verwechselt...

Deswegen wäre eine UDP basierte Anwendung als Server der Nachrichten verteilt nicht schlecht. Nur müssten die Clients halt auf UDP lauschen, das Senden von Nachrichten an den Server müsste dann mittels einer separaten TCP Komponente erfolgen, per UDP geht ja nicht.
Deswegen hab ich das ja auch mit TCP entwickelt, denn wenn man eh TCP braucht kann man darüber ja auch alles abwickeln, senden und empfangen (Clientseitig).

 

[alroar]

War nur so ne Idee.. aus meinen Anfangszeiten mit VB war mir halt UDP als wesentlich einfacher in der Umsetzung in Erinnerung geblieben.

Aber so: Wenn schon der Server per UDP raushaut, welchen Sinn hat dann noch TCP auf der Sendeseite? Ob jetzt nur 3 von 5 oder keiner das Paket bekommt... dann lieber letzteres. Oder eben Serverlos per Multicast

- Oder eben Clients per Multicast miteinander bekannt machen
- Per UDP oder Multicasts keepalives rumschicken um die Kontakte aktuell zu halten
- Per UDP oder TCP Nachrichten rumschicken

 

[fishmac]

Verwechsel hier UDP und TCP nicht.

UDP: ungesichert, keinerlei Empfangsbestätigung, Resend, freie Portwahl (...), kein Connection aufbau notwendig, etc...
TCP: Gesicherte Paketvermittlung, Verbindungs wird vorher aufgebaut (Socket), Pakete werden quittiert / ggf. neu angefordert

1.) Bei UDP gibt es auch freie Portwahl (zumindest so frei, wie bei TCP)
2.) Bei UDP gibt es auch Sockets
3.) Resend ? Nur auf Anfrage.