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
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
-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
-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
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.
-
x. Transports
struct protodefs protodefs[] contains definitions of the different