Disable DEBUG.

[radsecproxy.git] / develdoc.txt

diff --git a/develdoc.txt b/develdoc.txt
index d3ee6f7..05ee56e 100644 (file)
--- a/develdoc.txt
+++ b/develdoc.txt
@@ -135,7 +135,7 @@ reply by calling buf2radmsg(). If this fails or the message type
 is not one of Access Accept, Access Reject, Access Challenge or
 Accounting Response, the reply is ignored.
 
 is not one of Access Accept, Access Reject, Access Challenge or
 Accounting Response, the reply is ignored.
 

-If the request was a status-server message, it is simply removes
+If the request was a status-server message, it simply removes

 the request and returns.
 
 Next it will apply any rewritein rules and check TTL attribute if
 the request and returns.
 
 Next it will apply any rewritein rules and check TTL attribute if


@@ -152,15 +152,15 @@ sendreply() returns, we free the request from the server's
 request queue. This also means that the ID can be used for a new
 request.
 
 request queue. This also means that the ID can be used for a new
 request.
 

-Now about sendreply(). All it does, is basically to assemble the
+Now about sendreply(). All it does is basically to assemble the

 reply message, take care of authenticators and set rq->replybuf
 to point to the result. After that it adds a pointer to rq to
 reply message, take care of authenticators and set rq->replybuf
 to point to the result. After that it adds a pointer to rq to

-the clients reply queue, and signals the server writer who is
+the clients reply queue and signals the server writer who is

 responsible for sending replies to the client.
 
 The server writer is a separate thread created by the server reader,
 typically called something like xxxserverwr. All it does is to send
 responsible for sending replies to the client.
 
 The server writer is a separate thread created by the server reader,
 typically called something like xxxserverwr. All it does is to send

-whatever it finds in its replyq to the client and removes it. When
+whatever it finds in its replyq to the client and remove it. When

 the queue is empty it waits for a signal from a sendreply().
 
 The above shows the complete flow. It might be worth also looking a
 the queue is empty it waits for a signal from a sendreply().
 
 The above shows the complete flow. It might be worth also looking a


@@ -194,14 +194,12 @@ Finally, in sendreply() rq->replybuf is created from rq->msg, and
 rq->msg is freed. rq->replybuf is kept so that if a duplicate request
 is received later, we can just return rq->replybuf.
 
 rq->msg is freed. rq->replybuf is kept so that if a duplicate request
 is received later, we can just return rq->replybuf.
 

-It appears that rq->buf created by sendrq() is stored until the
-request is replaced, it should be freed when replyh replaces rq->msg
-or in freerqoutdata().
+rq->buf is removed by freerqoutdata(), because then we will not try
+to send the request in rq->buf any more.

 
 Request structs should perhaps be freed when they "expire", rather
 than wait until a new request with the same ID comes along.
 
 
 Request structs should perhaps be freed when they "expire", rather
 than wait until a new request with the same ID comes along.
 

-

 x. Transports
 
 struct protodefs protodefs[] contains definitions of the different
 x. Transports
 
 struct protodefs protodefs[] contains definitions of the different