[Xorp-hackers] Socket polling

[Victor Faion]

On Fri, Feb 13, 2009 at 19:56, Victor Faion <vfaion at gmail.com> wrote:
> On Fri, Feb 13, 2009 at 16:28, Victor Faion <vfaion at gmail.com> wrote:
>> On Thu, Feb 12, 2009 at 18:55, Pavlin Radoslavov
>> <pavlin at icsi.berkeley.edu> wrote:
>>> Victor Faion <vfaion at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I was trying to setup a process that tries connect to its neighbours
>>>> over TCP and basically I wanted it to keep trying to connect to its
>>>> neighbours until it can, but I was having some trouble as the process
>>>> basically stops trying to connect when it can't connect the first
>>>> time.
>>>>
>>>> I iterate over all the neighbour objects calling their connect
>>>> function which calls send_tcp_open_bind_connect. The callback given to
>>>> send_tcp_open_bind_connect just checks if there was an error and if
>>>> there was it calls connectRetry() which pretty much does the same
>>>> thing as connect (calls send_tcp_open_bind_connect and passes it the
>>>> same callback as connect). The problem is the first time when it calls
>>>> connect and fails, it just calls the socket4_user_0_1_error_event
>>>> function (saying ``Transport endpoint is not connected'' which is
>>>> expected) but then it doesn't go back into connectRetry() and no
>>>> connection is made when its neighbours are actually listening for this
>>>> connection. Is there a better/easier way of doing this polling or am I
>>>> just doing the recursing with the callback the wrong way?
>>>
>>> Is connectRetry() a method in your protocol?
>>>
>>
>>
>> Yeah, connect() takes in the parameters needed to call
>> send_tcp_open_bind_connect() and saves them into the Neighbour object.
>> Then connectRetry() uses the cached values to call
>> send_tcp_open_bind_connect() if it fails the first time.
>>
>>
>>> In your event handler for socket4_user_0_1_error_event you need to
>>> handle the error conditions (e.g., schedule a call to
>>> connectRetry()).
>>>
>>
>>
>> I tried to avoid this as this means iterating over all the neighbours
>> again, checking each sockid and matching against the sockid received
>> in socket4_user_0_1_error_event to figure out which neighbour's
>> connect function to call again. Anyway I tried doing it like this but
>> it still doesn't repeatedly try to connect to a neighbour. It goes in
>> this order:
>>
>> 1. Try to connect normally using the neighbour's conect() (shouldn't be able to)
>>
>> 2. Callback for send_tcp_open_bind_connect gets called (and the
>> XrlError object received is XrlError::OKAY() for some reason)
>>
>> 3. socketx_user_0_1_error_event gets called and says ``Transport
>> endpoint is not connected fatal''
>>
>> 4. Then socketx_user_0_1_error_event iterates over the neighbours,
>> when it matches the one which has the sockid that
>> socketx_user_0_1_error_event received it calls connect() again.
>>
>> 5. Then I get a warning that says ``Handling method for
>> socket4_user/0.1/error_event failed: XrlCmdError 102 Command failed
>> socket error''
>>
>> 6. Then the same thing as step 2 happens.
>>
>> The cycle ends there, connect() only gets called twice because
>> socketx_user_0_1_error_event only gets called once. Not sure why this
>> happens, something to do with that warning. Why does that happen
>> though?
>>
>>
>>> Also, are you saying that the first time you call
>>> send_tcp_open_bind_connect() and it fails, the callback for that XRL
>>> is not called at all? I would guess the callback might be called
>>> after socket4_user_0_1_error_event is received, but I wouldn't bet
>>> on the ordering.
>>>
>>> Pavlin
>>>
>>
>>
>> Well the callback gets called but the problem is that I'm not sure
>> which of the callback and the error event handler get called last in
>> order to reschedule the connecting.
>>
>> Victor
>>
>
>
> Sorry the reason for step 5 above was because my
> socket4_user_0_1_error_event was returning
> XrlCmdError::COMMAND_FAILED("socket error"). However when I changed it
> to return XrlCmdError::OKAY() basically it goes through steps 1-4 from
> above except sometimes, it doesn't happen in the order above but in
> the order 1, 3, 4, 2. When this happens it ends in step 2 and a
> connection is not made. This happens because the callback sets the
> sockid of the neighbour when a connection attempt is made, and the
> error handler uses this sockid to know which neighbour to connect to.
> So when the new sockid doesn't get set, the error handler doesn't find
> the neighbour. Not sure how to get the new sockid into the event
> handler when it doesn't get set into the callback.
>


Hello,

Sorry to restart this thread, I'm not sure how to handle the case when
a router cannot connect to another router. I don't understand why when
I call send_tcp_open_bind_connect to another router (which isn't even
online) the callback to send_tcp_open_bind_connect receives
XrlError::OKAY(). I wanted to handle this error in the callback as I
don't have enough information to handle it in the
socket4_user_0_1_error_event function. I couldn't find any code in
XORP that does this sort of thing. Where do the errors that get passed
into the callback for send_tcp_open_bind_connect get set?

Victor