summaryrefslogtreecommitdiff
path: root/ae/6007fc42ac0f23696d412584f5ce7b88c4c926
blob: c67beac4e42e1d463e26c1d078ca34d966c29fcd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from
	<SRS0=+sl2YcKg=UE=jerviss.org=bitcoin-devel@jerviss.org>)
	id 1VZvqE-0000C3-LR for bitcoin-development@lists.sourceforge.net;
	Sat, 26 Oct 2013 04:51:14 +0000
X-ACL-Warn: 
Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org)
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1VZvqD-0005CA-Kt
	for bitcoin-development@lists.sourceforge.net;
	Sat, 26 Oct 2013 04:51:14 +0000
Received: from [10.8.2.254] ([192.151.168.109])
	(username: kjj authenticated by PLAIN symmetric_key_bits=0)
	by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id r9Q4WWV4020840
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 25 Oct 2013 23:32:34 -0500
Message-ID: <526B45DB.2030200@jerviss.org>
Date: Fri, 25 Oct 2013 23:32:27 -0500
From: kjj <bitcoin-devel@jerviss.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
	rv:24.0) Gecko/20100101 SeaMonkey/2.21
MIME-Version: 1.0
To: Gavin <gavinandresen@gmail.com>,
	Jean-Paul Kogelman <jeanpaulkogelman@me.com>
References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com>
	<9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com>
In-Reply-To: <9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (inana.jerviss.org: 192.151.168.109 is authenticated by a
	trusted mechanism)
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: doubleclick.net]
X-Headers-End: 1VZvqD-0005CA-Kt
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 26 Oct 2013 04:51:14 -0000

The HTTP status code system seems to work well enough, and seems to give 
the best of both worlds.  A 3 digit numeric code that is 
machine-readable, and a freeform text note for humans.

The clever part about that system was in realizing that the numeric 
codes didn't need to account for every possible error. They just need to 
give the other node the most useful information, like "try that again 
later, I'm having a temporary problem" vs. "That is just plain wrong and 
it will still be wrong next time too, so don't bother to retry".

We can leave it to the humans to puzzle out the meaning of "403: values 
of txid gives rise to dom!"

Gavin wrote:
>
> On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman <jeanpaulkogelman@me.com> wrote:
>
>> Would it make sense to use either fixed length strings or maybe even enums?
> No. Enums or fixed length strings just make it harder to extend, for no benefit (bandwidth of 'reject' messages doesn't matter, they will be rare and are not relayed).
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development