Travis Cross wrote:
> Fredrik Thulin wrote:
>> I think the 'what-to-listen-on' should be made more generic. I have had
>> thoughts along the lines of
>>
>> {listen_on, ["tls:127.0.0.1:5061",
>> "tcp:192.0.2.11:5030",
>> "tcp:192.168.0.1:5060",
>> "udp:192.168.0.1:5060",
>> "tcp:[2001:6b0:5:987::1234]:5070",
>>
>> %% to bind to any address
>> "tcp:0.0.0.0:5060",
>> "tcp:[::]:5060",
>> %% or maybe better
>> "tcp:*:5060",
>>
>> %% and perhaps even things like
>> "192.168.0.1",
>> "some.dynamic.hostname"
>> ]}
>
> I've implemented something quite similar to your proposal. The
> patch against svn trunk is attached.
>
> To avoid extra parsing and making guesses, I kept a slightly more
> code-as-data format:
>
> {myips, ["192.168.1.100",
> "192.168.1.101",
> "127.0.0.1"]},
> {listen_on, [{tcp,"0.0.0.0",5060},
> {udp,"192.168.1.100",5060},
> {udp,"192.168.1.101",5060},
> {udp,"127.0.0.1",5061},
> {tcp,"192.168.1.100",5090},
> {tls,"192.168.1.100",5095}
> %{udp6,"2001:6b0:5:987::1234",5070},
> %{tcp6,"2001:6b0:5:987::4321",5080},
> %{tls6,"2001:6b0:5:987::4321",5085}
> ]}
>
> Since my machines are not configured for ipv6, the ipv6 part of the
> code has not received end-to-end testing.
>
> This change alleviates the issues I encountered on my machines when
> attempting to bind YXA to more than the first address on an
> interface. Since inet:getiflist / inet:ifget cannot be relied upon
> in this case, we need our own solution.
>
> It might seem surprising that the myips parameter is necessary in
> addition to the listen_on parameter. Given that the autodetection
> of IPs is unreliable in the presence of interfaces with multiple IP
> addresses, however, consider the following valid listen_on case:
>
> {myips, ["192.168.1.100",
> "192.168.1.101",
> "127.0.0.1"]},
> {listen_on, [{tcp,"0.0.0.0",5060},
> {udp,"0.0.0.0",5060},
> {tls,"0.0.0.0",5065}
> ]}
>
> Without the explicit myips configuration, it would be impossible to
> divine all of the IP addresses of this machine.
>
> If myips is not explicitly configured, the autodetection code still
> kicks in (siphost:get_ifiplist/0 - which on my machine would return
> only "192.168.1.100").
>
> I attempted to cleanly delimit throughout YXA the code that asks
> "what IPs are on this box?" from the code that needs to know "what
> listen specification should I use?", but you'll clearly want to look
> this over.
Hi again
I've had a closer look now - actually tried it out. While I believe you
have made a number of very good choices, I'm afraid that there are a few
important things you have overlooked, or more probably wasn't aware of.
* TLS and IPv6 can be turned off individually. To be fair though, I
realized that the original tcp_dispatcher:get_listenerspecs/0 didn't
check for IPv6 being disabled either =).
* TLS is not included in siphost:default_listen_list/0.
* With your patch, it is possible to listen to multiple different ports
of a specific protocol. While this is a good thing in itself, it comes
with a whole battery of ... interesting things to look into. When
receiving a request where we decide we need to put the port number in
the Via header, we should probably take care and put the exact port
number we received the request over in there, and likewise when we are
routing responses we can no longer just look for a connection to the
right remote IP:port, but must make sure that it is also with the
right local IP:port.
Also, when contributing code it is very much appreciated if you really
_really_ try to keep to the same coding style. With your code, the
differences are mostly that you don't put spaces after commas and that
you format your 'case' statements different than me in a number of
places. I know it sucks to have to think about coding style when
contributing, but it works the other way around too, when I'm
contributing to someone elses project ;)
To sum it up: I was going to include your patch in a snapshot I'm
preparing, but unfortunately it needs a bit more time than I have at my
disposal at the moment, so it will have to wait until you, me or someone
else finishes the work. In the mean time I'd suggest that you post on
erlang-questions about the root to your problem, which I'd say is an
Erlang/OTP issue, even if inet:getiflist/0 is undocumented and unsupported.
Thanks,
/Fredrik
_______________________________________________
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel
