On Thu, Apr 03, 2008 at 04:17:33PM +0200, pierrick grasland wrote:
> 1) IMHO, we don't have to allow persistence for more than a call .
> I'm hoping to detect a call Id, set a timer for this call Id,
> corresponding to persistence. But a phone call as a very variable
> time, from short call (less than 30s) to long call (more than 15
> minutes, and my stats are only based on my bills ^^).
> We can't allow a connexion logged as active for days, but if I'm in
> the following case (basic call flow in SIP) :
> Bob = INVITE => proxy1 = INVITE =>LVS = INVITE => realserver (proxy2)
> = INVITE ===> Alice
> Bob <= 200 OK = proxy1 <= 200 ok = LVS <= 200 ok = realserver
> (proxy2)<= 200 ok === Alice
> Bob = ACK => proxy1 = ACK =>LVS = ACK => realserver (proxy2) = ACK
> =========> Alice
> Bob <==========================RTP===============================> Alice
> Bob <= BYE = proxy1 <= BYE = LVS <= BYE = realserver <= BYE
> =============== Alice
> Bob = 200 OK => proxy1 = 200 OK =>LVS = 200 OK => realserver (proxy2)
> = 200 OK => Alice
> Then, we don't have SIP messages exchanged during the length of the
> communication, which use RTP. But, we must transfer the BYE in order
> to close the call.
> I think we have several options here :
> - hash (seems practical, but I don't know how it's react in case of
> addition / deletion of server)
> - timers
> - parsing sip headers in order to detect call terminaison, which seems
> totally impractical with a DR setup (we don't see all messages
> exchange from the 2 clients)
Yes, this all sounds very familiar.
The parsing approach sounds like a good idea, are you sure
that the packet-flow makes it impractical when DR is used?
It seems such a shame not to be able to use such a good idea.
The timeout idea is the most obvious approach, and probably the
best. But really long timeouts might well be needed. I mean,
its not uncommon for a phone call to go for several hours.
As for the hash, yes, I share your concern there.
> So, just for an example, I wish to know how do you implement
> persistence for HTTP.
> 2) I'm actually browsing sources from kernel 2.6.24 (just for a better
> idea on the architecture). I found IPVS in
> Does all sources are located in this folder ? Nothing with netfilter ?
There is also a header file, include/net/ip_vs.h
IPVS does use some of the netfilter code, but you probably
only need to study what is in net/ipv4/ipvs and include/net/ip_vs.h
to understand what is going on.
> PS : I have time to make something valuable (ie 4 months). I'm in
> internship, and this is my subject.
> Grasland Pierrick
> NEXCOM Systems
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html