Jerome Quelin wrote:
Show quoted text> my mistake, it's some remaining stuff from the original module that i
> inherited when i took over ownership.
>
> the original code was doing that, but:
> - it was buggy as hell, checking for timeouts but resulting in endless
> loops
> - network connections were not correctly monitored / reset / checked / etc.
>
> i therefore dumped this scheme for the safer (but slower) scheme:
> one connection per command
>
> i *know* it sucks, but network programming is a pita to do correctly.
>
> in the same time, i decided to try to write a poe module that would be
> better networking-wise, since poe would manage all the non-blocking
> socket i/o for me...
>
> (for the records, check
>
http://groups.google.fr/group/audio-mpd/browse_frm/thread/2a738cd980793cb0#de40453995def4ed
> for the discussion of this change. there are some references to parts of
> the old code, but...)
Something not mentioned in that thread is that every potential hang
mentioned there still exists in Audio::MPD. If the server crashes in
between it sending the password line and it sending the command, the
client will still hang, for example.
Show quoted text> > Is this planned to be fixed?
>
> i'm going to fix the documentation. not sure that releasing a 0.18.4
> version is worth it - what do you think?
Well, I might have skipped over trying the module if its docs had said
it needed one connection per command.
Show quoted text> regarding fixing the code: i'm not sure i want to go down that road.
> would you be interested to supply some patches to fix it? :-)
> (note that i cleaned up the code to always call the _send_command()
> method, therefore changing the connection scheme "only" means changing
> this method)
Well, it seems to me that you could add a flag that enables
an unsafe mode where one connection is reused, and if the server
times out/goes away/connection is dropped, the client is on its
own to notice this and avoid hanging. Or on its own to let it hang.
For certian types of clients, it doesn't really matter if they don't
deal gracefully with issues with the connection. For some others, it's
easy enough to set up an alarm and abort or retry.
IO::Socket::INET also has some options that can be used for simple
handling of timeouts, for some programs it might be enough for them to
get at and tune those options for their use cases.
Show quoted text> > Should I use the POE module instead?
>
> the poe module is indeed better for this: it keeps a connection open to
> the mpd server, and it reconnects automatically if somehow deconnected.
>
> having said that, please note that the poe module design is not
> finished. i'm not satisfied by its current api / internals, and i guess
> it might change in future releases. (it's mostly my fault, since it was
> the first poe programming that i've did)
I looked at it, but it seemed much more difficult to program for if I
want to do a simple client that runs some scripted set of commands.
Maybe there's an easy way to do that that I didn't see, I am not really
familiar with POE.
Show quoted text> however, if you are:
> - concerned by network latencies implied by audio::mpd (are you
> accessing a remote server? then how do you listen to the music? via some
> icecast?)
The particular cases where multiple connections annoyed me were
a) Writing a program to copy the state of one mpd to another,
I wanted to seek them to the same play position as closely as possible,
and this works less well than I'd have hoped since it has to open
a new connection to each, rather than using an existing open
connection, which would be much faster.
b) Writing a program to reverse the playlist, which involved a lot of
move operations, and this is where I really noticed it was
reconnecting per command, since the program is unusable with any
sizable playlist.
FWIW, my current set of code using Audio::MPD is at
git://git.kitenet.net/mpdtoys
--
see shy jo
