On Mon, Oct 17, 2011 at 5:30 AM, Amos Jeffries <[email protected]> wrote: > On 17/10/11 11:23, Andrew Beverley wrote: >> >> Hi, >> >> I've been using the qos_flows feature for preserving a netfilter mark, >> but have run into some problems. >> >> Currently, the netfilter mark for the connection is obtained in >> forward.cc, during the stages of opening a connection to the remote >> server. The problem with this is that the connection mark may change >> once the reply is received. >> >> So, I would like to move Ip::Qos::getNfmarkFromServer() from >> FwdState::dispatch to a function that is called during the server reply >> stage. However, I can't work out where it should go. >> >> I've looked at moving it to client_side_reply.cc, but I can't find a way >> to retrieve the remote server connection information. I've also looked >> at comm_read() in comm.cc, but I can't find the client connection >> information and it looks like the wrong place anyway. >> >> Where is the best place to move it to, where it has access to both the >> client and server side connection, but where it is late enough to read >> the mark value if it changes during the server reply? >> >> Hope this makes sense! >> > > FwdState::dispatch is called at the start of Server request sending. TO > start the construction and write of request headers to the server. > > For persistent and pinned connections it is essentially in the pause > position between end of reading one reply and start of sending the next > request. > > I think you mean that it may change on reading the first bytes of reply, > yes? > > In which case the best position is in HttpStateData::processReplyHeader(). > With matching positions in ftp.cc and tunnel.cc reply starting handlers. > The server connection is produced by a method dataConnection() of the state > object. > The client connection is not exposed. Although it could be. It is in the > parent ServerStateData::FwdState::clientConn.
Instead of moving it , why not doing both control points? like http_access / http_reply_access. It shouldn't hurt performance, and give greater flexibility.. -- /kinkie
