Sorry for the delay, stand by for further emails on this subject as well as the comments below...
On Mon, 2011-10-17 at 16:30 +1300, Amos Jeffries 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? Yes. > In which case the best position is in > HttpStateData::processReplyHeader(). What I actually meant was that it could change during the sending of data, as well as the first bytes. I'll explain further in a follow up email. > 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. > > Amos Andy
