[Xorp-hackers] Socket polling

[Victor Faion]

On Tue, Feb 17, 2009 at 17:54, Pavlin Radoslavov
<pavlin at icsi.berkeley.edu> wrote:
> Victor Faion <vfaion at gmail.com> wrote:
>
>> >> 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?
>> >
>> > For a reason that is unclear to me without further investigation,
>> > the order of the send_tcp_open_bind_connect callback and the
>> > socket4_user_0_1_error_event upcall are reversed
>> > (always/occasionally?). I had a quick look in the FEA, and the
>> > callback should be received first, but obviously from your
>> > description this doesn't seem to be the case.
>> > The correct solution should be to investigate the issue and fix it.
>> > This might require understanding of the FEA I/O internals and some
>> > XRL-related knowledge. Unfortunately, I can't give you an estimate
>> > how soon I/we can allocate the resources to fix that, so your best
>> > bet would be to submit a Bugzilla entry.
>> >
>>
>> Yeah they are reversed, I think it only happens when I reschedule
>> send_tcp_open_bind_connect from socket4_user_0_1_error_event. In that
>> case, it calls socket4_user_0_1_error_event before the callback.
>> I can submit a bug report, what sort of information should I include?
>
> A sample of the relevant code (pseudo-code is OK if the original
> code is too long), a brief description of what you think the
> expected behavior should be, description of what the actual behavior
> is, log output that might be relevant to the issue, and anything
> else that you think might help.
>
>> Here's the relevant output from when I start xorp_rtrmgr. At first it
>> attempts to connect normally, then goes to the callback, then
>> socket4_user_0_1_error_event, matches the sockid because it has been
>> set in the callback then attempts to reconnect to that IP. However
>> after this is goes back to socket4_user_0_1_error_event before the
>> callback (and so the new sockid is not set and there is no match and
>> no reconnection attempt).
>>

OK, I'm still not 100% sure it's a bug or that I'm just doing something wrong.

>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ] Connecting to 146.169.3.10
>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ] CB for
>> 92a9030b-02ba706b-0006c2a9-3c670000
>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ]
>> socketx_user_0_1_error_event 92a9030b-02ba706b-0006c2a9-3c670000
>> Transport endpoint is not connected fatal
>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ] sockid match: 146.169.3.10
>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ] connect retry
>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ]
>> socketx_user_0_1_error_event 92a9030b-02ba706b-0006d31d-3c670000
>> Transport endpoint is not connected fatal
>> [ 2009/02/17 12:06:07 INFO xorp_bpsf XrlBpsfTarget ] CB for
>> 92a9030b-02ba706b-0006d31d-3c670000
>
> A question that just came to mind trying to analyze the above log.
> if the original tcp_open_bind_connect call fails, are you sending
> again same XRL for same destination?
> This shouldn't be necessary, and I wonder whether this is relevant
> to the behavior you are seeing.
>
> If the connect failed, the FEA should send you either
> inbound_connect_event or outgoing_connect_event if the connection
> succeeded later. Note that this is what _should_ happen, but I don't
> know whether the FEA actually does the right thing.
>

I'm using instance_name() so for both calls the destination is
something like this:
bpsf-2c2e48eee1a7c19f0b55332900581229 at 127.0.0.1
Yep, both times it sends the send_tcp_open_bind_connect XRL.

If I don't resend the XRL it just ends in the error event handler
function and when the other router comes online, it doesn't receive an
inbound connection event. Are you saying the FEA should keep retrying
automatically? That would make things a lot simpler :-)

>
>> > For your own purpose you need to move forward by using some
>> > workaround. One possible solution that comes to mind is to have a
>> > map of states per sockid that can be populated/updated regardless of
>> > the order of the callbacks and the upcalls. E.g., if an upcall is
>> > received before the sockid is known, a new entry is created for that
>> > sockid and the state is set according to the upcall error. Then,
>> > after the send_tcp_open_bind_connect callback is invoked, at that
>> > time the sockid entry can be used for its intended purpose (and the
>> > error condition is already filled-in).
>>
>> Sounds good I will try to implement this :-)
>>
>> > On the other hand, if the upcall is inbound_connect_event or
>> > outbound_connect_event (instead of error_event), then only after the
>> > send_tcp_open_bind_connect callback is called, then you take the
>> > appropriate actions.
>> >
>>
>> Doesn't this also assume that
>> inbound_connect_event/outbound_connect_event get called after the
>> callback? (Not sure if this is what actually happens).
>
> I believe they should be called after the callback, but I am not
> sure this is what actually happens, so you would have to try it. If
> you see another case of reordered events, then you need to utilize the
> above workaround.
>
> Regards,
> Pavlin
>

OK, I will take a look at this.

Cheers,
Victor

>
>>
>> Thanks for the help, I'll try to use your suggestion and see how that goes.
>>
>> Victor
>>
>> _______________________________________________
>> Xorp-hackers mailing list
>> Xorp-hackers at icir.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>