Fragensteller
Client - asynchron

Allgemeine Diskussion
-
Hallo,
ich benötige noch den Fall, dass der Client auf einen Input reagiert.
Das könnte ich doch so realisieren.
Endlosschleife, mit dem Cancel bin ich mir nicht sicher.Problem:
Der Client muss empfangen können, also eventgesteuert und je nachdem was machen,
aber auch Senden können. Frage-Antwort. Also nochmals eine Anforderung.Empfangen, denke so wie unten dargestellt, kann ich aber eine Senderoutine einbauen, andere Funktion, ohne das Konflikte entstehen? Das wäre die Frage.
Wie immer, Danke für Tipps.
Viele Grüße Oliverpublic async void Start() { IPAddress[] IPs = new IPAddress[] { new IPAddress(_host) }; Socket s2 = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); LogMessage($"Establishing Connection to {_host[0]}.{_host[1]}.{_host[2]}.{_host[3]}"); s2.Connect(IPs[0], _port); LogMessage($"Connection established"); while (!MyToken.IsCancellationRequested) { //for (int i = 1; i < 10; i++) //{ // sck.SendSocket(s2, $"<command><notification>{Name} = {i}</notification></command>"); XElement rec = await sck.ReceiveSocket(s2); LogMessage($"Receive from Server:{Environment.NewLine}{rec.ToString()}"); //} Thread.Sleep(200); } LogMessage($"{Name}: alle Daten versendet."); }
- Typ geändert Dimitar DenkovMicrosoft contingent staff, Administrator Dienstag, 29. August 2017 11:11 Warten auf Rückmeldung
Alle Antworten
-
Hi Oliver,
Du solltest Dich mal wirklich mit dem TCP/IP beschäftigen. Ein Client kann keine Daten wie ein Server empfangen, also auf Daten vom Server warten, ohne vorher verbunden gewesen zu sein.Für Dein Ansinnen gibt es verschiedene Möglichkeiten:
1. Polling: Der Client fragt zyklisch (regelmäßig), ob der Server etwas zu "melden" hat. Das ist aber die ungünstigste Variante.
2. Der Client bekommt Daten vom Server als Response auf ein Request. Das entspricht in etwa dem Polling, aber indem Daten nur dann kommen, wenn "zufällig" ein Request abgesetzt wurde.
3. Im Client wird eine Server-Funktionalität implementiert. Das bedeutet, dass auch der Client auf Anforderungen vom anderen Rechner (Server) horcht, indem ein weiterer Port dafür genutzt wird. Zu Beginn meldet sich der Client beim Server und der Server führt eine Liste aller Clients, die sich angemeldet haben. In dieser Liste verwaltet der Server die Daten des Clients, um bei Bedarf selbst den Client über den anderen Port anzusprechen.
--
Viele Grüsse
Peter Fleischer (ehem. MVP)
Meine Homepage mit Tipps und Tricks -
Hallo Oliver,
Noch dazu würde ich dieses Tutorial über TCP/IP Socket Programmierung empfählen.
Viele Grüße
-
Hallo,>Im Client wird eine Server-Funktionalität implementiert. Das bedeutet, dass
>auch der Client auf Anforderungen vom anderen Rechner (Server) horchtja genau das muss ich umsetzen.
Allerdings gleicher Port.
Das sind die Anforderung und stammen nicht von mir.Server -- ClientClient sendet jede Sekunde ein Live Kommando.
Server antwortet.
Wenn nicht neu verbinden.Zusätzlich sendet der Server unbestimmt, also einen Event an den Client.
Grüße Oliver -
Hallo Oliver,
schau mal ob die beiden Links Dir weiterhelfen.
https://msdn.microsoft.com/en-us/library/system.net.sockets.socket.connected.aspxhttps://stackoverflow.com/questions/7650402/how-to-test-for-a-broken-connection-of-tcpclient-after-being-connected
Grüße Alexander
-
Hi Oliver,
wie soll das funktionieren? Gleichzeitig ist es unmöglich sowohl zu horchen als auch über den gleichen Port Requests zu senden. Wer solch ein ungewöhnliches Protokoll wünscht, sollte es etwas genauer spezifizieren, z.B. horcht der Client (arbeitet als Server) und beendet das Horchen, wenn er selbst ein Request senden will. Nach Ende der gesamten Übertragung incl. aller Ping-Pongs startet der Client wieder seine Server-Funktionalität. Ich habe solch ein eigenartiges Protokoll noch nie angetroffen.
--
Viele Grüsse
Peter Fleischer (ehem. MVP)
Meine Homepage mit Tipps und Tricks -
ja genau das muss ich umsetzen.
Allerdings gleicher Port.
Das sind die Anforderung und stammen nicht von mir.Ich nehme an, Du meinst einfach den Empfangsport und nicht den Sendeport!? Falls ja, musst Du dir einfach ein Servermodul als Listener erzeugen, dass Du dann in beiden Anwendungen einsetzt.
Gleichzeitig auf dem exakt gleichen Kanal senden und abhören (wenn nicht als Antwort auf eine Anforderung Richtung Server) wird nicht funktionieren.
Vollduplexbetrieb wäre IMHO eher sowas:
Client zu Server
Sendeport: 4711 (Client) zu Empfangsport: 80 (Server)
Server zu Client
Sendeport: 4711 (Server) zu Empfangsport: 80 (Client)
Das würde gehen, da es eben zwei Verbindungen sind, die auf jeweils getrennten Ports laufen. Ich habe die Ports im Beispiel nur gleichgehalten, da Du schriebst, das wäre eine der Basisanforderungen.---
Was hingegen wohl eher nicht funktionieren wird, wäre folgendes:
Client zu Server
Sendeport: 4711 (Client) zu Empfangsport: 80 (Server)
Server zu Client
Sendeport: 80 (Server) zu Empfangsport: 4711 (Client)
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
- Bearbeitet Stefan FalzModerator Dienstag, 12. September 2017 09:53