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

[Thomas Keller]

Am 08.10.2010 13:37, schrieb Masatake YAMATO:
>> 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:-)

As I said in my earlier mail, this might be good as temporary patch for
FC13's version of 0.48 - but is not needed at all for the trunk version.
See, resolve_service() is called indirectly through
Netxx::add_address(), which is indirectly called through Netxx::Address'
constructor.

When we build a stream to the server in the current trunk version
however, we guarantee that the address the Netxx lib sees does not
contain a scheme and as such it does not need to call resolve_service:

      // netsync_connection_info info;
      // bool use_ipv6;
      string host(info->client.get_uri().host);
      I(!host.empty());
      Netxx::Address addr(host.c_str(),
                          info->client.get_port(),
                          use_ipv6);

(netsync.cc, line 88ff, current trunk)

The problem in 0.48 is / was just that we gave netxx the complete URI,
not just the part it actually needed to build a stream to the server.

Netxx is also something we want to get rid of / replace for some time
now, because our in-tree copy of it is the only still "actively
maintained" version available (since almost 2005 actually). But there
are other threads which discuss this more in detail. Unfortunately the
developer who started working on the replacement once can't dedicate
more time on monotone.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature