On 17 Oct 2014, at 09:11, Br Achar <br.ac...@tcs.com> wrote:

> We are developing an iOS application for ipad that uses bonjour for conneting 
> with other devices and couchbaseListener for replications with peer 
> databases. We have observed that whenever [nsnetservice addresses] returns 
> IPV6 address ,replication is not suuccesful.We have tried encoding IPV6 last 
> two components sayfe80::68c8:cfff:fef9:3856 as 254.249.56.86 and using the 
> same in the url but still replications fail.

It's hard to say what's going on here with the details you've provided (for 
example, what sort of error do you get when replication fails) but the last 
part of the quote above piqued my interest.  Are you trying to build a URL from 
a resolved service?  If so, I recommend that you avoid the "addresses" array 
entirely and simply put the host name from the service into the URL.  Here's a 
snippet of code that does this for an _http._tcp. service.

- (NSURL *)URLForService:(NSNetService *)service {
    NSDictionary *      TXTRecordDictionary;
    NSURLComponents *   urlComponents;
    NSNumber *          portObj;
    NSInteger           port;
    NSURL *             url;
    
    assert(service != nil);

    // Get the port, defaulting to port 80.
    
    portObj = nil;
    port = [service port];
    if ( (port != 0) && (port != 80) ) {
        portObj = @(port);
    }
    
    // Build a set of URL components, using some default values, some values 
    // calculated above and some values directly from the service.
    
    urlComponents = [[NSURLComponents alloc] init];
    urlComponents.scheme   = @"http";
    urlComponents.host     = [service hostName];
    urlComponents.port     = portObj;
    
    // Create a URL form the components and return it.
    
    url = [urlComponents URL];
    assert(url != nil);
    
    return url;
}

The advantage of this is that it pushes off the question of address selection 
until connect time, and your connect-time code is better placed to decide which 
address to use.

Share and Enjoy
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (Macnetworkprog@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to