Re: Improving qos_flows mark feature - obtaining mark later

On Mon, Oct 17, 2011 at 5:30 AM, Amos Jeffries <squid3_at_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..

-- 
    /kinkie