proxy_outstanding

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

proxy_outstanding

Joe Maimon
Is only ever set to 1 from what I can grep of the code.

So when listen.c calls

/*
          *      Find the original request in the request list
          */
         oldreq = rl_find_proxy(packet);


which in turn executes

         node = rbtree_find(proxy_tree, &myrequest);

         if (node) {
                 maybe = rbtree_node2data(proxy_tree, node);
                 rad_assert(maybe->proxy_outstanding > 0);
                 maybe->proxy_outstanding--;

                 /*
                  *      Received all of the replies we expect.
                  *      delete it from both trees.
                  */
                 if (maybe->proxy_outstanding == 0) {
                         rl_delete_proxy(&myrequest, node);
                 }
         }
         pthread_mutex_unlock(&proxy_mutex);

         return maybe;

How can it be possible (what parts of the code have I not paid
sufficient attention to) for this to happen in listen.c ?


         /*
          *      If there is already a reply, maybe this one is a
          *      duplicate?
          */
         if (oldreq->proxy_reply) {
                 if (memcmp(oldreq->proxy_reply->vector,
                            packet->vector,
                            sizeof(oldreq->proxy_reply->vector)) == 0) {
                         radlog(L_ERR, "Discarding duplicate reply from
home server %s port %d  - ID: %d for request %d",
                                inet_ntop(packet->src_ipaddr.af,

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Reply | Threaded
Open this post in threaded view
|

Re: proxy_outstanding

Alan DeKok
Joe Maimon <[hidden email]> wrote:
> Is only ever set to 1 from what I can grep of the code.

  Did I mention that code sucks?

  I've bene looking into redesigning the "refresh_request" code, which
will touch this area, too.  I've been trying to avoid edge conditions,
race conditions, and still have the code readable, without the dumb
bugs it has today.

  So far, either I haven't had time, or I haven't been successful.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Reply | Threaded
Open this post in threaded view
|

Re: proxy_outstanding

Joe Maimon


Alan DeKok wrote:

> Joe Maimon <[hidden email]> wrote:
>
>>Is only ever set to 1 from what I can grep of the code.
>
>
>   Did I mention that code sucks?

As all my code looks far far worse, I can hardly say that. I chalk up
your pronouncment on the condition of the code as originating from your
excellent high standards.

>
>   I've bene looking into redesigning the "refresh_request" code, which
> will touch this area, too.  I've been trying to avoid edge conditions,
> race conditions, and still have the code readable, without the dumb
> bugs it has today.

I thank you and appreciate all the enormous efforts you and the other
developers put into freeradius, a truly outstanding product,
notwithstanding this details that I have found myself getting involved
in due to my predilection for using cvs unstable software.

>
>   So far, either I haven't had time, or I haven't been successful.

Whatever you manage to do, I will be gratefull and try to test it.

>
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Reply | Threaded
Open this post in threaded view
|

Re: proxy_outstanding

Alan DeKok
Joe Maimon <[hidden email]> wrote:
> I thank you and appreciate all the enormous efforts you and the other
> developers put into freeradius, a truly outstanding product,
> notwithstanding this details that I have found myself getting involved
> in due to my predilection for using cvs unstable software.

  Thanks.  Your comments have helped catch a few things we've missed.

  Before 2.0 is released, we need to:

  a) fix refresh_reques
  b) clean up realm & home server handling (which will add IPv6)
  c) patch rlm_eap to allow modules to link to each other
  d) write docs explaining the differences between 1.0 and 2.0

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Reply | Threaded
Open this post in threaded view
|

Re: proxy_outstanding

Frank Cusack
On October 7, 2005 1:48:37 PM -0400 Alan DeKok <[hidden email]> wrote:
>   Before 2.0 is released, we need to:

Release 1.1?  Or is that going to be skipped.

-frank
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Reply | Threaded
Open this post in threaded view
|

Re: proxy_outstanding

Alan DeKok
Frank Cusack <[hidden email]> wrote:
> Release 1.1?  Or is that going to be skipped.

  Given that the CVS head (mostly) supports IPv6, and has a whack of
other changes, I'd like to move to 2.0.

  This also lets us make minor but necessary incompatible changes, and
tell people "It's OK, because it's a major version rev".

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html