[Parti-discuss] TCP sockets (was xpra python dict error?)

[Nathaniel Smith]

On Thu, Feb 19, 2009 at 7:59 PM, Antoine Martin <antoine at nagafix.co.uk> wrote:
> Nathaniel Smith wrote:
>> NB, binding to localhost is not particularly sensible, because if
>> someone has access to the localhost interface then they can just use
>> the unix domain socket :-).
>
> Ooops, what I meant is a network interface of the local host.
> (ie: tun device)

Ohh, is this for getting to apps running on virt hosts? That makes more sense...

> Since it will be a define, I don't really care what the default is...

Yeah, me neither. Just, we should pick something that allows users not
to care either :-).

> I just thought X server + 4000 would be enough.
> According to my /etc/services file, only these ports are assigned by IANA:
> amanda          10080/tcp                       # amanda backup services
> amanda          10080/udp
> hkp             11371/tcp                       # OpenPGP HTTP Keyserver
> hkp             11371/udp                       # OpenPGP HTTP Keyserver
> bprd            13720/tcp                       # VERITAS NetBackup
> bprd            13720/udp
> bpdbm           13721/tcp                       # VERITAS NetBackup
> bpdbm           13721/udp
> bpjava-msvc     13722/tcp                       # BP Java MSVC Protocol
> bpjava-msvc     13722/udp
> vnetd           13724/tcp                       # Veritas Network Utility
> vnetd           13724/udp
> bpcd            13782/tcp                       # VERITAS NetBackup
> bpcd            13782/udp
> vopied          13783/tcp                       # VERITAS NetBackup
> vopied          13783/udp
> wnn6            22273/tcp                       # wnn6
> wnn6            22273/udp
>
> So maybe 14000 is better?

Sure, or 12000.

>> Mightn't it be better if we always listened on the unix socket, and if
>> we want to listen on TCP then do that in addition, rather than
>> instead? Then ssh-mode and tcp-mode can be used on the same server,
>> etc.
>
> Sure. Just 2 things:
> * if we do that, we lose the ability to automatically find the tcp  port
> number it is on if the offset is tweaked.  But I guess that if you tweak the
> offset when you start it, you can also apply the same offset when you "list"
> or "attach". And you can always use the socket for doing "stop". So that's
> ok.

Oh, right, finding the port again. Users might want to be able to do that.

The other option is to just leave out the "choose a different base
port" option. The port ends up being "a + b", where "b" is fully under
the user's control. So giving them control over "a" really doesn't
give them any extra power, but skipping it lets us avoid nasty and
confusing UI possibilities.

> * Not sure what the code will look like when listening to 2 sockets...
> A bit more work there... Any ideas on that?

This is actually really simple. Right now, the code does:
  make a socket
  register a callback on the socket that calls accept() and go from there
In the Brave New Multi-socket World, the code just does that twice.

Probably should refactor a bit, so that the socket creation and
binding happens in the script code, and XpraServer.__init__ just takes
a list of sockets and registers its callbacks on them. But that's just
polish.

>>> If so, how would you like me to send the patches? diff against trunk?
>>
>> That would be fine.
>
> Great. I'll get back to you with the patches asap. I'm working mostly
> offline at the moment so it might take a few days.

Cool.

-- Nathaniel