(Weis nicht ob Code Library oder hier)
Im Anhang befindet sich eine Komponente, welche:
-per UDP Broadcast automatisch alle anderen Komponenten im LAN aufspürt und sich zu denen verbindet
-eine
TCP-Verbindung zu jeder anderen Komponente hat (wenn gewünscht)
-Text, Zahlen oder Streams senden und natürlich auch empfangen kann
-inkl. UserListe
-mittels indirekter UDP-Port-Verwaltung auch mehrere Clients auf einem Rechner ermöglicht
mehr fällt mir jetzt nicht ein
Ein kleines Beispiel hängt auch an.
Ja, und es sind zwei Komponenten, die eine TLanConnectStream hat über TLanConnect nur die Erweiterung der Streams
Prinzipiell kann man die Komponente instanzieren, einen UserNamen vergeben und aktivieren und bekommt über OnChangeUser (+TLanConnect.Clientusers oder TLanConnect.Clientsockets) schon mitgeteilt wer noch im LAN zur Verfügung ist.
An diejenigen kann man dann per SendText, SendNumber,... Sendxxx etwas verschicken. Die Glücklichen erhalten die Nachricht in den dazugehörigen OnRecievexxx-Ereignissen.
Das war dann auch schon alles.
Man kann wie gesagt auch Streams senden. Aber hier liegt der Teufel drin (deswegen auch noch keiner 1-er Version). Derzeit funktioniert zwar alles, aber mal sehen, wo der nächtse Fehler auftritt.
Achtung: Man muss die Streams nach dem Senden immer selber freigeben (auf das Ereignis warten)!
Kurze Funktionserklärung (was macht die Komponente im Hintergrund am Anfang):
1. Einrichten eines
TCP-ServerSockets
2. Einrichten eines UDP-Sockets auf vereinbarter Portzahl oder indirekt auf einem anderne Port und anmelden bei der anscheinend vorhandenen anderen Instanz, welche den Port schon belegt (Indirekter UDP-Modus)
3. Versenden von BroadCast-Messages mit LanName und
TCP-ServerSocket-Portnummer
4. Darauf reagieren alle Komponenten im LAN, welche denselben LANNamen benutzen und Verbinden sich mittels
TCP zum ServerSocket
5. Austausch von Usernamen und Hostnamen
6. ab hier kann gesendet werden
Eigenschaften:
-auschließliche Verwendung von WINSOCK (
WinAPI)
-Alle
TCP-clients einer Komponente benutzen den gleichen Port
-komplett ereignissgesteuert (allerdings mit Hagens Delay-Funktion [ohne Verwendung von TApplication], wenn der Socket zum Schreiben blockiert ist)
-keine Verwendung von Threads (kann man aber problemlos in einen Thread legen)
So, ich glaube ich habe erstmal alles. (genauere Erklärungen kommen vielleicht noch)