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
