Re: Improving qos_flows mark feature - obtaining mark later

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
Received on Mon Oct 31 2011 - 20:42:04 MDT