Netzwerk-kommunikation OHNE Server? (Chat)

[dommes89]

Hallo...

Eine Frage:

Und zwar bin ich auf der Suche nach einem Netzwerk-Chat..

Habe da auch schon so einiges gefunden..... allerdings mit Server...

Jedoch suche ich eine Möglichkeit wie ich das ganze OHNE Server hinbekommen kann... Habe schon einige Chats ohne Server gefunden, jedoch kein Java.

Nun die Frage:

Weiss einer eine Methode wie ich dies mit Java lösen kann?

Habe schon einen Chat geschrieben... dieser jedoch schreibt und liest aus einer Datei... Ich möchte das ganze jedoch Dateilos über das Netzwerk machen... und ohne dass irgendwo ein Server läuft..

Hoffe jemand hat da Ideen wie ich das ganze hinbekommen könnte bzw. irgendwelche Quellen wo dies schonmal gemacht wurde...

Vielen Dank schonmal

[robotto7831a]

Hallo,

wo sollen sich denn die Chatmitglieder anmelden wenn es keinen Server gibt? Oder sollen immer nur zwei Leute chatten können?

Frank

[Amstelchen]

wenn rechner A und rechner B direkt (ohne "server") kommunizieren wollen, muss halt A einen socket anbieten (server) und B zu diesem verbinden (client).

"ohne dass irgendwo ein server läuft" wird so nicht realisierbar sein, da immer einer von den zumindest zwei parteien einen TCP-port anbieten muss.

s'Amstel

[dommes89]

Okay das stimmt...

Aber gibt es nicht die möglichkeit, dass user A den socket anbietet und B und C darauf zu greifen, dann wenn user A das Programm schließt user B oder C den Socket übernimmt?

Denn die anderen Chats die ich gefunden haben funktionieren ja auch ohne dass iwo noch ein Server läuft...

gruß

[flashpixx]

Wäre nicht eine Multicast Systematik sinnvoller?

Phil

[Amstelchen]

sobald irgendein rechner irgendeinen port anbietet, ist das schon definitionsgemäss ein server. das geht garnicht anders.

s'Amstel

[dommes89]

@flashpixx

wie läuft das mit dem multicast?

[flashpixx]

Naja jedes Chatprogramm muss sowohl Server- wie auch Clientsocket haben, aber sie werden an eine Multicastadresse gebunden: Multicast ? Wikipedia

Phil

[VaNaTiC]

Genau vor demselben Problem stand ich vor knapp 10 Jahren als ich einen kleinen Chat programmiert hab, damals mit MailSlots.

Später dann mit UDP, was in meinen Augen der beste Kompromiss ist.

Wie bereits gesagt wurde, ist Fakt, dass ohne einen Port an dem Einer horcht nix geht. Auch bei MultiCast ist das so.

Mit UDP ist das ziemlich easy zu machen, jeder Client macht einfach einen festgelegten Port auf. Und dann sendet man mittels UDP-Broadcasts (255.255.255.255) wenn erlaubt oder Broadcast an Netzadresse an alle ein UDP-Paket.

Problem ist nur - und da hab ich damals aufgehört - wenn man das auf einem TerminalServer startet, wo dann dummerweise der Port bereits belegt ist, dann muss man das ganze auf Port-Ranges erweitern.

[dommes89]

Okay nach langer Sucher habe ich nun ein paar Programme gefunden, die genau das tun was ich möchte...

Für diejenigen die sie sich mal anschauen möchten:

kouchat

MC2 Chat

Das sind nun mal 2 Beispiele die wirklich gut sind und ohne Server laufen und auch funktionieren...

Mein einziges Problem:

Ich habe bei beiden noch nicht rausgefunden, auf welche art sie das machen, eventuell hat ja einer mal lust sich eines davon anzuschauen (beide sind open source) und eventuell den entscheidenden Teil dann zu berichten.

Ichwerde mir das jetzt auch noch weiter genauer anschauen...

Gruß

[VaNaTiC]

Beide über MultiCast.

Der Vorteil von MultiCast in diesem Szenario ist, dass man sich sozusagen mit Öffen eines Ports registriert zum Empfang der Pakete die dieser Gruppe verteilt.

UDP-Broadcasts empfangen ersteinmal alle erreichbaren Teilnehmer. Auch die welche keinen Port offen haben. Das sehen Admins halt einfach nicht gern

Bearbeitet 16. März 2009 von VaNaTiC

[dommes89]

Hmm.. okay.

Du hattest gemeint du hättest dich damit schonmal beschäftigt.

Weisst du wo es eine gute Quelle gibt bei der ich mich in das Thema MultiCast in Java bezüglich meines Vorhabens einlesen kann?

Danke

[speedi]

Denkbar wäre auch eine Mischung aus UDP-Broadcast und TCP-Socket.

1. Das Programm erzeugt, einen UDP broadcast "WER ISSN HIER DER SERVER?"

2. Der Server antwortet mit einem gerichteten UDP-Packet "SERVER:NAME"

3. Das Programm öffnet eine TCP-Verbindung zum Server

Sollte kein Server gefunden werden, macht das fragende Programm selbst den Server.

Sollte der Server beendet werden, handeln die Clients über UDP wieder aus wer den Server macht (z.B. der mit der niedrigsten IP-Adresse).

Admins würde das wohl kaum ins Auge stechen, da die Menge der Daten die über Broadcasts läuft eher gering ist und Boadcasts keine seltenheit in Netzwerken sind - solang sie sich in einem gewissen Rahmen bewegen.

[VaNaTiC]

MultiCast in Java, leider nein, denn das ist ein allgemeines Thema und wird nur in der jeweiligen Sprache implementiert.

Mein Chat war damals in Delphi mit UDP-Broadcasts.

Aber ich hab vorhin mal durch wiki-Link von flashpixx geblättert, das schaut prima aus.

[dommes89]

Hmm.. okay..

Ja habe jetzt anhand von diesem Simplen Beispiel (link) es jetzt mal hinbekommen =)

Habe das entscheidende beim receiven zum test in ne endlos schleife gesteckt und dann mit der send klasse verschiedene texte gesendet.. Kollege ebenso... Hat sehr gut funktioniert =)

Jetzt ist das ganze dann natürlich auch kein problem mehr es noch weiter auszubauen...

Aber falls jemand trozdem noch ideen und quellen hat immer her damit =)

[dommes89]

Okay nun stehe ich vor einem weiteren Problem:

Wie kann ich denn bestimmte Informationen übermitteln?

Wie zum Beispiel User-Name der angemeldet ist, denn dieses Datagramm liefert mir nur IP-Adresse und Port und so Sachen...

Aber wie sehe ich denn z.B. wenn ich mich einlogge, wer alles bereits eingeloggt ist... Also die Informationen die ich sehen möchte.... Name, Anzahl, ID .. usw....?!

gruß

Bearbeitet 18. März 2009 von dommes89

[VaNaTiC]

Sowas nennt man dann anwendungsspezifisches Protokoll und gehört zur OSI7. UDP ist zB nur für den Transport zuständig.

Du musst Dir halt jetzt den Aufbau und möglichen Inhalt Deiner Chat-Pakete überlegen.

So nach dem Motto (Trennzeichen | ):

Broadcast/AnAlle -> HIALLE|IchBinDerNeue|MeineVersion|Schnulli

EinzelnVonAllen <- HIDU|IchBinEiner|MeineVersion|Schnulli

Damit kann man zum Beispiel schonmal beim Anwendungsstart und eventuell zyklisch alle paar Minuten Updates der UserListe fahren.

Wenn nun einer einen Text absendet, dann schreibts einfach:

Broadcast/AnAlle -> TEXT|Das ist ein simpler - auch mehrzeiliger - Text.

Einzigstes Problem ist, dass Du generell bei UDP (auch bei MultiCast) die Paketlänge begrenzen musst. Lange Texte kann man zum Beispiel einfach trennen. Man kann sogar ignorieren, dass eventuell das zweite Paket das erste überholt. Ist nicht so schlimm

Ich würde die Paketlänge auf etwa 1000+Header begrenzen und dann splitten.

Hinweis: Wunder Dich nicht, dass Du Deine eigenen abgesendeten Pakete wie jeder andere auch empfängst. Wenn Du das nicht willst musst Du das entweder beim Senden verhindern (find ich schwieriger) oder beim Empfangen Deinen eigenen Absende-Port ausfiltern (einfacher).

Bearbeitet 18. März 2009 von VaNaTiC

[dommes89]

So in etwa habe ich mir das auch überlegt... und dann halt anhand des Textes die UserListe zusammenbasteln...

Aber eine andere Idee:

Ist es bei Multicast auch möglich Objekte zu versenden?

Dann könnte man ja zum Beispiel ein Interface anlegen, das die ganzen Informationen enthält und dieses eine eigene zum Beispiel an alle anderen Senden...

ICH ----> UserInformation | AN_ALLE

Ich hab da ein Beispiel gefunden welches sich aber an Sockets Richtet, mit MulticastSockets leider nicht... das ganze nennt sich dann ObjectOutputStream / ObjectInputStream ....

Würde es damit evtl. gehn?

Gruß

Bearbeitet 18. März 2009 von dommes89

[flashpixx]

Ist es bei Multicast auch möglich Objekte zu versenden?

Im Grunde her ja, nennt sich serialisieren und gibt es als Interface für Java. Was ich Dir aber empfehlen würde, schau Dir diesbezügl. RMI an

Remote Method Invocation ? Wikipedia

Galileo Computing :: Java ist auch eine Insel (8. Auflage) – 14.12 Persistente Objekte und Serialisierung

Phil

[dommes89]

Ja also das mit dem serialisieren habe ich auch schon iwo gelesen und auch schon benutzt, jedoch ist das Problem, dass ich den ObjectOutputStream nicht mit dem MulticastSocket verwenden kann... iwie klappt das nur mit normalen Sockets, da mir MulticastSocket nicht den getOutputStream() anbietet...

Und wenn ich es mit normalem Socket probiere bring er mir:

connect: Address is invalid on local machine, or port is not valid on remote machine

iwie muss das doch aber gehen das ganze im Multicast anzuwenden oder?

Das mit dem RMI muss ich mir mal genauer anschauen...

[VaNaTiC]

Was bietet den der MultiCast-Socket zum Senden, wenn es keinen OutputStream gibt?

CORBA, RMI und Derivate wie WebServices sind für Deinen Anwendungsfall nicht die beste Wahl, denn die arbeiten alle mit TCP und das ist nicht MultiCast.

Dein Weg in Richtung serialisieren der Objekte übers Netzwerk ist brauchbar, aber Du musst Dich trotzdem darum kümmern, dass auf HIALLE ein HIDU und das dazugehörige Handling passiert.

Und da ist es egal, ob HIDU per Text, Befehlsbyte oder Objekt erkannt wird.

Bearbeitet 18. März 2009 von VaNaTiC

[dommes89]

Japp für RMI usw. habe ich keine Verwendung... Das ist wirder zu Server abhängig...

Habe das ganze nun aber Hinbekommen indem ich mein Objekt mittels ObjectOutputStream in einen ByteArrayOutputStream geschrieben habe und diesen dann per DatagrammPacket gesendet habe...

Empfang dann entsprechend umgekehrt...

ByteArrayOutputStream baos = new ByteArrayOutputStream();

			ObjectOutputStream oos = new ObjectOutputStream(baos);


			oos.writeObject(user);

			oos.flush();

			oos.close();


		      DatagramPacket pack = new DatagramPacket(baos.toByteArray(), baos.size(),

		      					 InetAddress.getByName(group), port);


		      s.send(pack,(byte)ttl);

war zwar ein rumgefuchtel aber hat dann am ende geklappt ^^

Jetzt muss ich nur noch beim Empfangen unterscheiden ob es ein String ist oder ein Objekt wie User...

Falls da jemand eine idee hat wär ich natürlich dankbar =)

(Also ohne dass irgendwie dazu geschrieben wird "String" oder "User")

gruß

[flashpixx]

Wie wäre es denn, wenn Du eine komplette Nachricht erst einmal als XML ablegst. Du kannst via JaxB Dir direkt Factory Klassen erzeugen lassen, somit sprichst Du Deine XML als Objekt an.

Als ersten Schritt entwirfst Du eine XSD (Schemadatei) wie eine komplette Nachricht aussehen soll, z.B. Name des User, Onlinezeit, Textnachricht ggf mit Formatierungen und ggf binäre Daten. Aus der XSD erzeugst Du die Factory Klassen und kannst dann eben über ein Javaobjekte diese XML erzeugen. Versendet wird dann die XML und beim Empfänger wird die XML wieder in ein Objekt gewandelt mit dem Du arbeitest.

Vorteil davon ist, es ist ein strukturiertes Dokument, das versendet wird. Es ist flexibel und erweiterbar ohne, dass Du direkt alles neu schreiben musst, da Du im Grunde bei Änderungen nur die Factory Klassen neu erzeugst

Phil

[VaNaTiC]

flashpixx hat Recht inbezug auf serialisieren von Objekten.

Serialisieren (hier speziell ObjectOutputStream) hat einen Nachteil: es ist eine andere Darstellung eines flüchtigen Objektes. D.h. die binäre Darstellung des Objektes im Speicher kann sich durchaus ändern.

Deshalb benutzt man für die persistente Darstellung von Objekten auch irgendein objectrelationales Mapping. Das kann XML sein, das kann aber auch auch was eigenes sein.

Wichtig ist nur, Du solltest aufpassen, dass Du Dir nicht wieder ein neues Problem ins Haus holst. Das ist "nur" ein Chat über MultiCast.

OR-Mapping ist da meiner Meinung nach mit Kanonen auf Spatzen.

Gleichzeitig hat XML den Nachteil, dass der erzeugte Text relativ zum Objekt gesehen enorm groß ist. Das Mapping dauert zusätzlich natürlich auch Zeit!

Und Du darfst nicht vergessen, MultiCast und UDP übertragen Daten pro Paket zusammengehörend.

Fakt ist, wenn Du die Dinger als Text besser sogar noch binär überträgst, dann kostet Dich das etwas mehr Aufwand beim Entwickeln, aber ist robuster und performanter!

just my 2 cents

[flashpixx]

Falls fragen bzügl Jaxb usw sind, kannst Du mich auch so anschreiben. Ich entwickel zurzeit etwas ähnliches in Matlab mit Jaxb

@VaNaTiC mehr als ein full ack kann man da nicht mehr sagen :uli

Phil