kader990 / android-rcs-ims-stack

Automatically exported from code.google.com/p/android-rcs-ims-stack
0 stars 0 forks source link

Partial SRV implementation #60

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The current code appears to only consider the SRV record with the highest 
weight regardless of the assigned priority or other SRV records with the same 
priority level. It does not do proportional round-robin.

test  IN SRV 1 75  serverA
test  IN SRV 1 25  serverB
test  IN SRV 2 100 serverC

This should round robin over serverA and serverB in a ratio of 75:25. serverC 
should only see traffic if both serverA and serverB are down.  The current 
client sends all traffic to serverC as it has the highest listed weight.

The relevant section in the code appears to be:

private SRVRecord getBestDnsSRV(Record[] records)
loops through the records and does:
 if ((result == null) || (srv.getWeight() > weight)) {
                                result = srv;
                                weight = srv.getWeight();
                        }

Original issue reported on code.google.com by jvbeu...@gmail.com on 15 Mar 2012 at 8:09

GoogleCodeExporter commented 9 years ago

Original comment by jmauffret@gmail.com on 15 Mar 2012 at 9:30

GoogleCodeExporter commented 9 years ago

Original comment by jmauffret@gmail.com on 2 Apr 2012 at 7:01

GoogleCodeExporter commented 9 years ago
Thank you. The fix to the reversed priority order is much appreciated and will 
greatly help in an environment with multiple client vendors.  

My interpretation of the code as it stands currently is that only the host with 
the lowest priority and the highest weight is considered.  Only if two records 
have the same priority and weight will this implementation probably do load 
balancing, due to the random ordering of the records as returned by the DNS 
server.  I do think resolving the remaining issue with the proportional 
round-robin and fail-back capabilities of SRV could make the client more 
robust. It is something we intend to use.

The SRV record could also be used for RCS clients in a port-restrictive wifi 
environment, by advertising different ports that can be updated centrally 
within DNS:

_sip._udp.rcs.mydomain.com    IN    SRV 1 1 5060 demohost.mydomain
_sip._udp.rcs.mydomain.com    IN    SRV 1 0 5061 demohost.mydomain
_sip._tcp.rcs.mydomain.com    IN    SRV 1 1 5060 demohost.mydomain
_sip._tcp.rcs.mydomain.com    IN    SRV 1 0 80   demohost.mydomain
_sip._tcp.rcs.mydomain.com    IN    SRV 1 0 443  demohost.mydomain

Original comment by jvbeu...@gmail.com on 3 Apr 2012 at 2:34