monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Updated Issue 119 - Server startup requires interface /


From: code
Subject: [Monotone-devel] Updated Issue 119 - Server startup requires interface / hostname (monotone)
Date: Mon, 21 Feb 2011 00:08:47 +0100 (CET)

Hello,

The following issue has been updated:

119 - Server startup requires interface / hostname
Project: monotone
Status: Fixed
Reported by: Thomas Keller
URL: https://code.monotone.ca/p/monotone/issues/119/
Labels:
 Type:Incorrect Behavior
 Priority:Medium
 Milestone:1.0

Comments (last first):

# By Thomas Keller, Feb 21, 2011:

Fixed in revision 05b4d62389d9d181f188ce73e76c6d859f7a5eb3

 Status: Fixed

# By Thomas Keller, Jan 14, 2011:

Any comments on this one? If not, I'd continue.

 Status: Accepted
 Owner: tommyd

# By Thomas Keller, Dec 28, 2010:



 Labels: Milestone:1.0

# By Thomas Keller, Dec 26, 2010:

Steps to reproduce the problem:
-------------------------------

$ mtn serve --bind :4691

Expected result:
----------------

beginning service on <all interfaces> : 4691


Actual results:
---------------

mtn: misuse: unable to parse host of URI ':4691'


Output of `mtn version --full`:
-------------------------------

mtn 0.99.1


Problem is in network/connection_info.cc, line526ff and furthermore in keys.cc, 
line 188ff: When we try to figure out the proper key to use for netsync (client 
OR server), we ask the user via get_netsync_key. This is however always done 
with the client connection's URI resource, which should not be set at all for 
the server, but which we set (half-wrongly already) to the first --bind 
parameter the user gives us.

To do this properly once and for all, I propose we split up 
get_netsync_key(server, include, exclude) into get_client_netsync_key(server, 
include, exclude) and get_server_netsync_key(servers) - the latter carries a 
table of addresses it got via --bind instead of a single address.
To ease the handling of the chosen key somewhat, I think it might be a good 
idea to carry the whatever chosen key afterwards in the connection_info struct, 
shared by both, client and server.



--
Issue: https://code.monotone.ca/p/monotone/issues/119/



reply via email to

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