Re: Newbie needs help with IO::Socket (maybe IO::Select)
- From: xhoster@xxxxxxxxx
- Date: 29 Feb 2008 17:14:45 GMT
"Boerni" <john@xxxxxxx> wrote:
Hi all
I'm playing around with IO::Socket and try to build a small Client/Server
App.
The Serverpart is working as it's supposed to, but I have some problems
with the Clientpart.
So I have a couple of Questions:
1. How can a Client react to a Servermessage (Server prints to Socket),
when it's not expecting a Servermessage (For example another client
connects to the server and kicks the first one or the server is beeing
shutdown).
Why would another client connecting to the server kick off the first one?
Wouldn't it be easier to fix this problem than to deal with the
consequences?
If the server has gone away, the client will realize this next time it
tries to communicate with it. While I guess it might be nice to know
immediately that the server has gone away, plenty of very good
client-server apps don't detect server failure until the next time it tries
to communicate. I'd need a very compelling reason not to follow this
paradigm for my own clients.
If I use the IO::Select approach like in the Serverpart, the
Client is blocked and the User can't interact with it anymore.
You need to add STDIN (or whatever you use to communicate with the User)
into the IO::Select, too. This means you probably have to use sysread,
rather than <>, to read from STDIN.
.....
#Pruefen ob ein Client connectet
while(1) {
my ($neu_lesbare) = IO::Select->select($lesbar, undef, undef, undef);
foreach $socket(@{$neu_lesbare}) {
if ($socket == $main_socket) {
#Neue Verbindung kommt rein...
my $neues_socket = $socket->accept();
$lesbar->add($neues_socket);
}
else {
# Hier drin passiert Zeug mit dem Client
my $buf = <$socket>;
You are mixing buffered IO with select. This is rather dangerous. If
the client can ever print two (or more) lines into $socket in quick
succession, then this code might cause both of them to be read into the
perl internal buffer, but only one of them to be returned from there
into $buf. The next line just sits in the internal buffer, where it will
not trigger IO::Select and hence not get read. The client won't send any
more lines (which would trigger IO::Select) because it is waiting for a
response to the last line it sent, and the server will never respond to
that line because it doesn't know that it is there. Deadlock.
I think IO::Select (or some subclass thereof) should return readable for
any file handle that has data sitting in the perl internal buffer, in
addition to the handles that have data (or eof) in the system's buffers. I
haven't quite figured out how to implement that. All of those globs and
glob refs and PerlIO layers and tied handles and scalar masquerading as
handles are just too much for me.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
.
- References:
- Newbie needs help with IO::Socket (maybe IO::Select)
- From: Boerni
- Newbie needs help with IO::Socket (maybe IO::Select)
- Prev by Date: Hell of a time extracting bits from a vector
- Next by Date: Re: Secure FTP
- Previous by thread: Newbie needs help with IO::Socket (maybe IO::Select)
- Next by thread: Hell of a time extracting bits from a vector
- Index(es):
Relevant Pages
|
|
