Opened by #Kein Kommentar at 2010-03-30 14:49
User since
2004-07-19
1776 Artikel
HausmeisterIn
![[Homepage]](/battie/theme/default/homepage.gif)
2004-07-19
1776 Artikel
HausmeisterIn
Programme die die CGI-Schnittstelle nutzen haben prinzipiell nichts mit Netzwerken zu tun. Auch wenn sie in aller Regel von Webservern ausgeführt werden um Inhalte für einen Browser oder auch ein anderes Programm auf der Clientseite zu generieren, übernimmt die Netzwerkkommunikation hier vollständig der Webserver, nicht das CGI.
Vermutlich suchst Du eher nach einer Anleitung für
IO::Socket.
Im Prinzip ist das alles ganz einfach: Sobald Client und Server einmal verbunden sind, haben sie beide ein Dateihandle in der Hand, bei dem Daten, die eine Seite reinschreibt auf der anderen Seite beim Lesen wieder herauskommen. So ein Handle nennt man auch einen Socket. Wie man an so ein Handle kommt, unterscheidet sich ein wenig zwischen Client- und Serverseite, denn schließlich muss sich die Asymmetrie, dass viele Clients sich mit einem Server verbinden können, zu jeder Clientverbindung aber genau ein Server gehört, auch in der API widerspiegeln. Der Client benutzt so etwas wie
der Server hingegen braucht einen Socket, der nur auf Verbindungen von Clients wartet, und jeweils einen für die Kommunikation mit den verbundenen Clients:
Natürlich muss man sich auf der Serverseite noch Gedanken machen, wie man Verbindungen von mehreren Clients parallel behandelt. Und es gibt einen Haufen Details, die in Bezug auf Sockets interessant sind -- nichtblockierendes Lesen und Schreiben zum Beispiel oder auch andere Protokolle als TCP. Es ist aber wenig Magie dabei sondern funktioniert nicht viel anders als Datenein- und Ausgabe mit Dateien.
Ein gutes Tutorial zur Socketprogrammierung mit Perl fällt mir auf Anhieb aber leider nicht ein.
Vermutlich suchst Du eher nach einer Anleitung für
IO::Socket.Im Prinzip ist das alles ganz einfach: Sobald Client und Server einmal verbunden sind, haben sie beide ein Dateihandle in der Hand, bei dem Daten, die eine Seite reinschreibt auf der anderen Seite beim Lesen wieder herauskommen. So ein Handle nennt man auch einen Socket. Wie man an so ein Handle kommt, unterscheidet sich ein wenig zwischen Client- und Serverseite, denn schließlich muss sich die Asymmetrie, dass viele Clients sich mit einem Server verbinden können, zu jeder Clientverbindung aber genau ein Server gehört, auch in der API widerspiegeln. Der Client benutzt so etwas wie
Code (perl): (dl
)
1 2 3 4 5 6 7
my $server = IO::Socket::INET->new( PeerHost => 'some.server.example', PeerPort => 42, Proto => 'tcp' ); my $server_said = <$server>;
der Server hingegen braucht einen Socket, der nur auf Verbindungen von Clients wartet, und jeweils einen für die Kommunikation mit den verbundenen Clients:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9
my $listener = IO::Socket::INET->new( Listen => 4, LocalPort => 42, Proto => 'tcp' ); my $client = $listener->accept(); my $client_said = <$client>;
Natürlich muss man sich auf der Serverseite noch Gedanken machen, wie man Verbindungen von mehreren Clients parallel behandelt. Und es gibt einen Haufen Details, die in Bezug auf Sockets interessant sind -- nichtblockierendes Lesen und Schreiben zum Beispiel oder auch andere Protokolle als TCP. Es ist aber wenig Magie dabei sondern funktioniert nicht viel anders als Datenein- und Ausgabe mit Dateien.
Ein gutes Tutorial zur Socketprogrammierung mit Perl fällt mir auf Anhieb aber leider nicht ein.
When C++ is your hammer, every problem looks like your thumb.