Re: sockets giving me gray hairs. server keeps dying
am 02.04.2008 10:58:01 von lekonnaOn Mar 29, 6:42 am, fishfry
> In article
> <584aaebe-3585-409f-b29c-6be83ba52...@s12g2000prg.googlegroups.com>,
>
> lekonna
> > Hi guys,
> > i'm having bit of a hard time getting my very simple multiplexing
> > socket server staying alive. It keeps exiting without giving any
> > messages, and since i'm running the bugger in while(1) loop i don't
> > quite get why the heck it does that.
>
> One thing you can do any time a program is "dying for no reason," [which
> of course really means, dying for some reason that we don't yet
> understand :-)] is to declare a DIE handler, and in the handler, write a
> log message and a stack trace.
>
> Secondly, in the same vein, your program should already be copiously
> sprinkled with log messages, saying "I'm doing this," and, "I'm getting
> ready to do that." Of course you will disable those messages when you
> roll your code to production; but during development, and especially
> during EARLY development, they are invaluable. If you had a lot of log
> messages in your code, you'd know the last thing your server did before
> it died.
>
> > Its a very basic echo server with some added features for keeping
> > track of users. Basicly i wanted to learn how to use sockets in flash
> > and needed something to echo the poo that i send back to me so i came
> > up with this quick and dirty solution. Now unfortunately it seems that
> > the trusty old work-horse perl keeps dying on me.
>
> One thing I truly know in this world is that sockets work perfectly well
> in Perl. I'm going to go way out on a limb here and say that the problem
> is probably in your code :-)
>
> > Heres the link to attachr with syntax highlighted version of the
> > server implementation.
> >http://attachr.com/10605
>
> > very basic server with some ugly xml hacks in it.
>
> > Is there a way to enable some sort of debug info on what actually goes
> > wrong?
>
> I didn't look at your code. But if you take my suggestions to write log
> messages before and after every interesting thing your program does
> (startup, init, creating/opening/connecting sockets, etc.); and
> implementing DIE and WARN handlers, you will soon see what's going on.
> The idea is to equip your program with the means to debug itself.
>
> One more thing that comes to mind is that people learning to write
> servers often have trouble with the logic of handling a connection
> request using the accept() function. To service a connection request you
> have to fork a child process to handle that client; or you have to
> handle the client yourself, managing multiple sockets: the listening
> socket, on which you receive connection requests; and one for each
> connected client. Typically you need to use non-blocking sockets in
> conjunction with the select() call. [And note that "select" is very
> unfortunately overloaded in Perl to a totally different function that
> has the exact same name but has nothing to do with it!]
>
> It wouldn't hurt to review your accept() logic.
>
> Hope this helps.
Thanks for the reply, actually this implementation isn't a multi
threading one, wanted to try out an single threaded version for
change. the thing is that on my windows machine the server runs
smoothly but dies without an explanation every now and then on the
linux 64bit machine.
Since there are no exit points inside the while true loop and no error
messages are output i can only phantom that it is some kind of bug in
the actual library i'm using itself. browsed quickly through the 5.8.8
x86_64-linux-thread-multi/IO lib but couldn't find a way to enable any
more debug messages as it is.
This is a tricky one, still no solution. I do believe the problem is
in my logic but seem to be unable to find more info on where we
actually exited from.