Opened 6 years ago

Closed 5 years ago

#238 closed defect (wontfix)

synchronous IP autodetect

Reported by: dawuud Owned by:
Priority: major Milestone: undecided
Component: network Version: 0.7.0
Keywords: Cc:

Description

i'm not a fan of autodetect but if we have to have autodetect then it looks like it can be implemented synchronously like this: https://stackoverflow.com/questions/166506/finding-local-ip-addresses-using-pythons-stdlib/166591#166591

using this python module which makes this operation way more portable than os.subprocess... https://pypi.python.org/pypi/netifaces

note that this task is part of tasks: http://foolscap.lothar.com/trac/ticket/236 https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2491 https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:31

Change History (5)

comment:1 Changed 6 years ago by dawuud

This or something like it should work and be very portable... in my dev branch: https://github.com/david415/foolscap/tree/238.synchronous-ip-autodetect.0

Am I expected to write unit tests for this? At the very least the test should fail if an empty list is returned. Note that this netifaces module also supports IPv6...

comment:2 Changed 6 years ago by Brian Warner

BTW I think this code is going to live in Tahoe, not Foolscap. Do we have a Tahoe ticket for it?

comment:3 Changed 6 years ago by dawuud

there's this... we could rename the ticket...

"synchronous node startup" https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2491

comment:4 Changed 6 years ago by Brian Warner

Component: unknownnetwork

comment:5 Changed 5 years ago by Brian Warner

Resolution: wontfix
Status: newclosed

We've decided to stop doing autodetection: applications will either have to do address-detection / port-allocation themselves, or (better) be told these values through user-provided configuration data.

So this ticket can go away.

Note: See TracTickets for help on using tickets.