none
Client - asynchron RRS feed

  • 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 Oliver

    public 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.");
    }
    

    Mittwoch, 16. August 2017 16:40

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

    Donnerstag, 17. August 2017 06:10
  • Hallo Oliver,

    Noch dazu würde ich dieses Tutorial über TCP/IP Socket Programmierung empfählen.

    Viele Grüße

    Donnerstag, 17. August 2017 12:31

  • Hallo,
    >Im Client wird eine Server-Funktionalität implementiert. Das bedeutet, dass
    >auch der Client auf Anforderungen vom anderen Rechner (Server) horcht
    ja genau das muss ich umsetzen.
    Allerdings gleicher Port.
    Das sind die Anforderung und stammen nicht von mir.
    Server -- Client
    Client 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
    Donnerstag, 17. August 2017 17:31
  • Hallo Oliver,

    schau mal ob die beiden Links Dir weiterhelfen.
    https://msdn.microsoft.com/en-us/library/system.net.sockets.socket.connected.aspx

    https://stackoverflow.com/questions/7650402/how-to-test-for-a-broken-connection-of-tcpclient-after-being-connected

    Grüße Alexander

    Donnerstag, 17. August 2017 17:53
  • 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

    Donnerstag, 17. August 2017 18:44
  • Hallo Dimitar,

    Du schreibst ja warten auf Rückmeldung.

    Ich meinte halt einen Vollduplexbetrieb.

    Grüße Oliver

    Montag, 11. September 2017 20:34
  • 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


    Dienstag, 12. September 2017 09:51
    Moderator