[erlang-questions] Socket connects to itself
Tue Oct 13 08:53:19 CEST 2009
In C you could of course check the bound port before connecting.
And I guess the same fix could be applied to prim_inet if that is what
you want ;-)
On 13 okt 2009, at 00.12, Per Hedeland wrote:
> Rob Charlton <rob@REDACTED> wrote:
>> I noticed in the logs one night that this process P which had tried
>> several hours to connect to a non-existent server on 127.0.0.1:2920
>> actually succeeded! Even more exciting than that, it had connected to
>> itself, so when it started trying to communicate with its peer it was
>> very surprised to receive its own communications back again.
>> Needless to
>> say P crashed at this point. I was very curious to know how this
>> happen and to try and fix it! You could argue this isn't a bug
>> the system configuration was incorrectly specified. In this
>> case though, the misconfiguration can happen easily and I would
>> like P
>> not to crash but instead to keep trying.
>> I tried Googling for this and did find a couple of non-erlang sources
>> suggesting it had happened to them in similar circumstances. It
>> could be
>> that this is a very timing sensitive 'feature' of TCP/IP. Can anyone
>> enlighten me?
> That's a nice one!:-) Whenever you call gen_tcp:connect(), the
> underlying OS connect() system call will first bind the socket to a
> local address and port, and then send the initial SYN packet using
> address/port as source. It is quite possible that at some point it may
> happen to choose the unused port 2920 for that, and hence attempt a
> connect from 127.0.0.1:2920 to 127.0.0.1:2920.
> This is where the "feature" comes into play - you might think that
> connection should fail, since there is no process listening on port
> 2920, but the TCP spec explicitly prescribes that "simultaneous
> initiation" should be handled - e.g. from section 2.7 of RFC 793:
> Two processes which issue active OPENs to each
> other at the same time will be correctly connected. This flexibility
> is critical for the support of distributed computing in which
> components act asynchronously with respect to each other.
> You can also see it in the famous state diagram in Figure 6 of RFC
> as the "rcv SYN" transition from SYN_SENT to SYN_RCVD. Though of
> it's a pretty safe bet that no protocol in serious use actually
> this "critical" functionality.
> --Per Hedeland
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
More information about the erlang-questions