monotone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-users] Getting the sourece code for the latest monotone?


From: Masatake YAMATO
Subject: Re: [Monotone-users] Getting the sourece code for the latest monotone?
Date: Fri, 08 Oct 2010 20:37:49 +0900 (JST)

> Am Thu, 07 Oct 2010 14:59:18 +0200
> schrieb Thomas Keller <address@hidden>:
> 
>> > 'mtn pull' worked fine after adding
>> > 
>> >     mtn        4691/tcp                # Monotone Network Protocol
>> >     mtn        4691/udp                # Monotone Network Protocol
>> > 
>> > to /etc/services. The lines for monotone were already there:
>> > 
>> >     monotone        4691/tcp                # Monotone Network
>> > Protocol monotone        4691/udp                # Monotone Network
>> > Protocol
>> > 
>> > 
>> > Do you think this is bug of /etc/services?
>> > 
>> > I don't think so. /etc/services is distributed so widely, I think
>> > mtn command should lookup "monotone" service if "mtn" cannot be
>> > found.  
>> 
>> Hrm... this is an interesting problem I never came across myself.
>> Thomas Moschny is also Fedora user - Thomas, did you stumble across
>> this one before?
> 
> No, and I didn't even know that monotone calls getservbyname(3). So
> indeed we should (a) get that changed via IANA somehow and (b) try to
> ask for the 'mtn' service first, and if that fails also for 'monotone'.
> 
> This is afaik not a Fedora issue. The entries in the /etc/services file
> are not maintained by the respective package maintainers.

I like (b). If the modification (b) is applied to monotone 0.48, the
executable of the version is good enough for me: it can get the latest
version of monotone.

...I found another solutions: (c) try to ask for the 'mtn' service
first, and if that fails just return 0; as the result
netsync_default_port(== 4691) is used.


netsync_default_port is defined in 
monotone/0.48-1.fc14/pre-build/monotone-0.48/constants.hh:
  std::size_t const netsync_default_port = 4691;

getservbyname is invoked in Netxx::resolve_service of 
0.48-1.fc14/pre-build/monotone-0.48/netxx/resolve_getaddrinfo.cxx:
    Netxx::port_type Netxx::resolve_service (const char *service)
    {
        addrinfo flags;
        addrinfo *info;

        std::memset(&flags, 0, sizeof(flags));
        flags.ai_family = AF_INET;

        if (getaddrinfo(0, service, &flags, &info) != 0) {
            std::string error("service name resolution failed for: "); error += 
service;
            throw NetworkException(error);
        }

        auto_addrinfo ai(info);
        return ntohs(reinterpret_cast<sockaddr_in*>(info->ai_addr)->sin_port);
    }


The exception raised from Netxx::resolve_service causes following message:

    $ mtn pull -d :monotone  
'mtn://code.monotone.ca/monotone?net.venge.monotone'
    ...
    mtn: network error: service name resolution failed for: mtn

Instead of raising an exception, just returning 0 may be enough. 

Netxx::resolve_service of 
0.48-1.fc14/pre-build/monotone-0.48/netxx/resolve_getservbyname.cxx
is implementated as I wrote:

    //####################################################################
    Netxx::port_type Netxx::resolve_service (const char *service)
    {
        servent *se;

        // WARNING not thread safe :-(
        if ( (se = getservbyname(service, "tcp")) != 0) return 
ntohs(se->s_port);
        return 0;
    }
    //####################################################################

I'm quite happy if (b) or (c) is available on F13:-)

Masatake YAMATO



reply via email to

[Prev in Thread] Current Thread [Next in Thread]