WebSocket Server tut nicht (Allgemeines zu Perl)

[thread]18493[/thread]

WebSocket Server tut nicht

Tags: perl5 Ähnliche Threads

Leser: 22

Articles: hide open all | hide show old branches

+4 replies
Xorg1990

2013-08-04 11:58
User since
2013-05-25
8 Artikel
BenutzerIn
Hi, ich habe ein Problem mit dem Modul Net::WebSocket::Server.
Ich wollte eine TCP Verbindung „anzapfen“ und die Daten in eine WebSockt Verbindung schreiben als Stream sozusagen.

Mit folgenden Code greife ich auf die TCP Verbindung zu:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11

$socket = new IO::Socket::INET ( PeerHost => '127.0.0.1', PeerPort => '3000', Proto => 'tcp', ) or die "ERROR in Socket Creation : $!\n"; print "TCP Connection Success.\n"; #while (sysread($socket, $byte, 1)== 1) { # print STDOUT $byte; # }
Das funktioniert soweit. Nun will ich die while schleife in Net::WebSocket::Server
ausführen, aber das funktioniert nicht.
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Net::WebSocket::Server->new( listen => 5000, silence_max => 0, on_connect => sub { my ($serv, $conn) = @_; $conn->on( binary => sub { while (sysread($socket, $byte, 1)== 1){ $conn->send_binary($byte) for $conn->server->connections; } }, ); }, )->start;
Das Problem habe ich schon erkannt, die Schleife wird bei "binary" ausgeführt und da es eine Endlosschleife ist kommt der Perl Interpreter nicht bi zu ->start.

Wie könnte man das am besten lösen?
Vor lauter ->, =>, sub{}, Blicke ich hier nicht mehr durch.
- +3 replies
- murphy
  
  2013-08-05 12:58
  
  User since
  2004-07-19
  1776 Artikel
  HausmeisterIn
  
  2013-08-04T09:58:48 Xorg1990
  [...]
  Das Problem habe ich schon erkannt, die Schleife wird bei "binary" ausgeführt und da es eine Endlosschleife ist kommt der Perl Interpreter nicht bi zu ->start.
  [...]
  
  Das ist nicht korrekt: Die Schleife steckt in einer Subroutine, die erst später innerhalb von ->start eventuell irgendwann mal aufgerufen wird. Wenn sie allerdings aufgerufen wird, hängt sie das Programm in eine Endlosschleife.
  
  Der Code ist einfach semantisch nicht sinnvoll. In Deutsch übersetzt bedeuten Deine Anweisungen an den Computer etwa folgendes: Erzeuge einen neuen Websocket-Server und starte eine Ereignisschleife dafür; wann immer sich jemand mit dem Server verbunden und eine binäre Nachricht an ihn geschickt hat, starte eine Endlosschleife, die von einem anderen Dateideskriptor jeweils ein Byte liest und dieses als Nachricht an alle Clients, die mit dem Websocketserver verbunden sind, weiterschickt.
  
  Ein ereignisgesteuerter Programmablauf lässt sich nicht auf diese Weise mit einer Schleife verbinden. Da Net::WebSocket::Server offenbar keine Schnittstellen zum I/O-Multiplexing bietet, wird es eventuell schwierig, das Problem korrekt zu lösen. Vielleicht lässt sich mit Threads etwas Funktionierendes basteln.
  When C++ is your hammer, every problem looks like your thumb.
  - +2 replies
  - Xorg1990
    
    2013-08-05 14:49
    
    User since
    2013-05-25
    8 Artikel
    BenutzerIn
    
    I/O-Multiplexing, Threads? Jetzt bin ich völlig durcheinander.
    
    I/O = Ein/Ausgabe, Multiplexing = Bündeln und Versenden, soweit habe ich das verstanden. Aber ist das nicht der Sinn einer WebSocket Verbindung mehrere Anfragen zu verarbeiten und darauf ohne Latenz zu antworten. Auch wenn ich mit meinen Script die Socket Verbindung nicht voll ausnutze, ich sende ja immer nur in eine Richtung.
    
    Threads:
    Mit Threads meinst du bestimmt multi-threading. Da habe ich das gefunden:
    threads
    Damit habe ich mich noch nie befasst. Ich habe bis jetzt immer mit PHP und JavaScript gearbeitet und da gibt es kein multi-threading.
    
    Der ganze Aufwand ist nur weil es keine Möglichkeit gibt Gstreamer mit der Web Audio API zu verbinden. Der einzige Weg ist die Daten in eine WebSocket Verbindung zu schieben.
    - topeg
      
      2013-08-05 16:13
      
      User since
      2006-07-10
      2611 Artikel
      BenutzerIn
      
      Wie Net::WebSocket::Server funktioniert:
      
      Nachdem der Server gestartet ist wartet er auf eine Verbindung, wird diese hergestellt startet der Server einen Subprozess er auf Nachrichten von diesem Socket wartet.
      
      Kommt eine Nachricht, werden die vorher angebenden Handler gestartet. Handler bedeutet hier so viel wie "Code der Aktionen handhabt".
      Handler werden auch Hooks genannte weil sie sich an bestimmten Stellen in den Code "hängen". Oder auch Code-Calls Weil sie dem Modul fremden Code aufrufen.
      
      "Event-Handler" sind sind hier Codeabschnitte, die bei bestimmten Aktionen aufgerufen werden wie während einer Websocket-Sitzung auftreten können.
      
      Handler sind Subroutienen in denen du Schreibst was an bestimmten Stellen im Programmablauf des Servers passieren soll. Die Stellen definieren gewisse Aktionen.
      
      Eine Aktion ist z.B der Verbindungsaufbau oder der Abbau einer Verbindung. Für dich interessant sind die Aktionen, die beim Empfang einer Nachricht und beim Verbindungsaufbau ausgeführt werden.
      
      Einer dieser Handler ist on_connect. Der darin enthaltene Programmcode wird ausgeführt wenn sich ein Client mit dem Server verbindet.
      
      Bei dir wird dann code ausgeführt der für diese Verbindung Handler erzeugt. Du setzt den Handler binary dieser wird immer dann aufgerufen wenn eine Nachricht auf diesem Websocket an den Server gesendet wird. Die Nachricht wird nicht weiter verarbeitet und formatiert sondern so wie sie kommt an den Handler übergeben.
      
      Alles was du machen musst ist die Nachricht anzunehmen und zu verarbeiten.
      Es werden keinerlei Schleifen gebraucht. Das macht alles der Server für dich.
      
      Das Konzept eines Handlers ist zuerst ungewohnt, wenn man normalerweise prozedural Programmiert und sich nie über Funktionsreferenzen Gedanken gemacht hat. Es erlaubt aber eine sehr elegante und einfache Programmierung, wenn man das Konzept verstanden hat.
      
      Ein Problem ist, das einem der "Main-Loop" aus der Hand genommen wird. Als "Main-Loop" bezeichnet man die Schleife, die Den ganzen Programmcode umfasst. In diesem wird auf Eingaben reagiert, Reaktionen auf Aktionen ausgelöst usw. In machen fällen ist es wichtig selber Aktionen in den Main-Loop zu setzen, um z.b regelmäßige Aktionen ausführen zu können. Dieses Modul bietet keine Möglichkeit Code in den Main-loop zu setzen.
      Aus dem Grund wurde "Threads" angesprochen. Threads erlauben "neben läufige" Programmierung. Damit ist gemeint, dass man mehrere Programmteile Nebeneinander Ausführen kann, die möglichst zu selben Zeit ausgeführt werden. Man kann es sich so vorstellen, das man mehrere Programme hat die auf einfache weise Miteinander kommunizieren können. Dabei gibt es aber durchaus ein paar Sachen zu beachten, aber ich gehe erst darauf ein wenn es nötig sein sollte.
      
      Für dich reicht es erst mal zu wissen das dieser Code funktioniert:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
      
      #!/usr/bin/perl use strict; use warnings; use Net::WebSocket::Server; Net::WebSocket::Server->new( listen => 5000, silence_max => 0, on_connect => sub { my ($serv, $conn) = @_; $conn->on( binary => sub { my ( $conn, $message ) = @_; $conn->send_binary($message); }, ); }, )->start;

View all threads created 2013-08-04 11:58.