search

livepeer / go-livepeer-basicnet

Basic p2p video streaming for Livepeer
MIT License
18 stars 8 forks source link

Now we can just use 0.0.0.0 - infered by the libp2p chat example #44

Closed ericxtang closed 6 years ago

ericxtang commented 6 years ago

This was breaking our connection logic because we were listening on the wrong interface.

j0sh commented 6 years ago

Trying to understand this behavior. I actually checked the bindings earlier today and it only seems to bind to one IP for the interface, whereas AWS gives us an internal /20 per host. Also, I'm not sure which corresponds to host's public IP (if there is even a correspondence). But I'm still not sure how exactly the libp2p update broke that (unless it was listening to 0.0.0.0 under the hood the whole time).

ericxtang commented 6 years ago

I'm not sure what changes caused this issue - the only thing I did was try to follow the new libp2p example and isolate the difference. I'll reach out to the protocol labs team about it.

Btw, 0.0.0.0 apparently breaks out tests because it makes the tests significantly slower to the point that it eventually times out. So I still use addrutil.InterfaceAddresses() for when running tests, but expose the option to use 0.0.0.0 for users of the SDK.

Left a question here for the libp2p team - https://github.com/libp2p/go-addr-util/issues/12

j0sh commented 6 years ago

I like the method of passing in the binding multiaddrs explicitly. For the tests we can probably simplify by binding to 127.0.0.1 alone.

Since we still need an explicit address for TranscodeSub, it'd be good to see if the Protocol Labs team has any insight on the change.