On May 9, 2008, at 2:14 AM, Christer Holmberg wrote: > > I don't understand Juha's argument about proxies "knowing things". > > If a UA does not register an outbound flow via a certain proxy that > proxy doesn't have to know anything about other proxies, because no > call > to/from the UA will ever go through that proxy. >
The real question is to which proxy in a cluster of proxies should requests to you be sent? Typically a cluster of proxies will be represented by multiple SRV records. Assume there are N proxies in the cluster. If your UA is registered to all N, then any of them will work. It doesn't matter which SRV record gets picked. Assume now that a flow drops between your UA and one of those N proxies. However, according to the DNS, that proxy is still authoritative for your domain, and it might get a request meant for you. What does that proxy do if it gets a request for you? Returning a 404 would be uncool. So it has to be able to figure out which of the other proxies in the pool have a flow with your UA. In a shared-state system, some sort of database (which could be distributed, centralized, bus-multicast, whatever) informs every proxy in the cluster about your flow-bindings (either as they come and go, or on demand). A proxy (like the one above) that has lost its flow for your UA uses this to find a proxy that has a flow with your UA in order to send a request. There are all sorts of optimization hacks and approaches for making this work more efficiently or more manageably. One nifty technique is to pair up the proxies, such that there are N/2 pairs, then define a hash across the namespace that maps to each user ID to one of those pairs, Your UA will then end up registering to and forming a flow with both proxies in its assigned pair. Other proxies in the pool that receive a request for you can use the hash to find the right pair, and if either proxy in the pair has lost the flow, it knows to consult the other member of the pair. If a whole pair goes down for service (or a new pair gets brought on-line), the hash algorithm gets updated and the system rebalances. Another approach is to consider the set of N proxies a ring, and define a hash on the namespace across the N proxies, where your UA ends up registered to the proxy to which it is hashed (call it M) and the (M+1)modN proxy. This gives a smoother distribution curve. Or one could use an even fancier hash (or pair of hashes) to pick two proxies that are not adjacent. This buys some advantages if the allocation algorithm works to make a local proxy "preferred" and a non-local proxy "secondary" for each user -- this way, if one data center crashes, we don't have a real avalanche restart. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
