[pulseaudio-discuss] Pull request: Autospawn fix

Lennart Poettering lennart at poettering.net
Wed Jan 13 15:19:27 PST 2010


On Wed, 13.01.10 22:15, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> >>>  3. Do not have a "default" pulseaudio TCP port and thus do not try and
> >>> connect (like 1. but more far reaching). Currently only one user on a
> >>> system can load TCP, but if multiple users want to use it to SSH out and
> >>> run applications this is bad. The networking module should load and try
> >>> to listen on a pool of TCP ports (e.g. a range of numbers for
> >>> firewalling ease) As the TCP port number is put into the x11
> >>> PULSE_SERVER property, it doesn't actually matter that the number is
> >>> standard. The module should randomly pick numbers from the pool (or
> >>> count up) until it finds one it can use (e.g. not already bound).
> >>
> >> Hmm, sounds reasonable to me. In fact the kernel will assign a port
> >> number automatically if the user binds to port 0. We should probably
> >> make that the default unless things are run in system mode or
> >> so. Should be a trivial fix.
> > 
> > Haven't implemented this now, because it requires API changes to
> > pa_socket_server_new_ipv4() and friends which kinda sucks.
> 
> Sucky indeed. FWIW I don't think we should use totally random ports as
> it makes it harder to open firewall ports to cope with PA... If we knew
> PA always used e.g. 10000-10099 then we could open those ports easily.
> It's maybe not really something we should worry about tho' as the ideal
> situation is to teach SSH how to tunnel the connection just like it does
> for X for the majority of network connection use cases.

I think it is kinda neat if the kernel picks the port number. Which is
what I implemented now. People really shouldn't allow access to a PA
server through the internet, so I don't feel bad making things
difficult for them ;-)

> Migration may suck for users who are used to turning on networking +
> auth-anon (or even just copying their cookie) in paprefs and then using
> PA remotely.... wonder how we can deal with that :s

As long as only one user does that things should work exactly as they
did before because we default to the traditional ports. The difference
is only visible when two users enable the module in which case this
will now work (though with a different port number) where it failed
before.

This is all now implemented.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



More information about the pulseaudio-discuss mailing list