[erlang-questions] Socket connects to itself

[Per Hedeland]

Tony Rogvall <tony@REDACTED> wrote:
>
>On 13 okt 2009, at 12.37, Per Hedeland wrote:
>
>> Tony Rogvall <tony@REDACTED> wrote:
>>>
>>> In C you could of course check the bound port before connecting.
>>
>> Actually no, you couldn't, since the bind happens implicitly as part  
>> of
>> the connect() call. What you *could* do in C but not in Erlang would  
>> be
>> to explicitly bind the socket before the connect, but of course that
>> carries a whole can of worms that you really don't want to open for  
>> this
>> case.
>
>Hmm. I normally bind my ports before connecting ;-)

You do such weird things...:-)

> Sometime you
>need to control the source address and source port.

Yes, in some rare cases you do, but in 99.9% of them the kernel knows
better than you, and you'll just risk messing things up that way -
e.g. binding to an address that isn't reachable from the destination.
Not to mention trying to bind to a "free" port different from the
destination port, to avoid the problem here.

> So that is also
>what Erlang does ;-) The connect defaults to bind to ifaddr = any and  
>port = 0

Ah, it was a while since I last had the pleasure of digging through that
code, my memory is fading...

>This bind, I guess, is the operating system default so the feature/ 
>problem reported
>may occur anyway.

Indeed, such a bind should never be problematic, but is also just a
waste of cycles.

>The check would probably be a bit hard to implement anyway. If connect
>is connecting to a local address and the socket is bound to any  
>(0.0.0.0) address,
>the way to determine if this connect is an "invalid" connect, one must  
>scan
>the interface addresses and probably the routing tables (and more) to  
>see
>if this case will apply.?

Well, you could take a simpler approach and just consider it invalid if
the port was the same as the destination port. I'm not sure that there
is a fool-proof way (for all implementations) to make sure that you
don't get the same port again if you re-try, though...

> Is this the "can" you where talking about ;-)

No, rather the problems that you can run into if you try to bind to a
*specific* address/port (unless you really need to), per above.

--Per