On Mon, 2011-10-17 at 10:03 +0200, Kinkie wrote: > On Mon, Oct 17, 2011 at 5:30 AM, Amos Jeffries <squ...@treenet.co.nz> 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..
I don't think that there is much point to having it in both places, as the value is only used when sending data to the client. Something like this will happen: the mark will be retrieved during the request to the server and saved (as now); the mark will then be retrieved again during the server reply; and then the mark will be used to mark packets leaving Squid to the client. I think it makes sense just to retrieve the mark during the server reply stage and use that. Andy
