Re: Improving qos_flows mark feature - obtaining mark later

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.

Amos
Received on Mon Oct 17 2011 - 03:31:04 MDT