blob: 9d8e2f556a807e6f5c4821603dc305b3a6f09031 (
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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <shadders.del@gmail.com>) id 1R1ZmF-00086X-Th
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Sep 2011 08:16:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.47 as permitted sender)
client-ip=209.85.218.47; envelope-from=shadders.del@gmail.com;
helo=mail-yi0-f47.google.com;
Received: from mail-yi0-f47.google.com ([209.85.218.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R1ZmF-0003Id-78
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Sep 2011 08:16:03 +0000
Received: by yia28 with SMTP id 28so533081yia.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 08 Sep 2011 01:15:57 -0700 (PDT)
Received: by 10.100.131.18 with SMTP id e18mr342623and.14.1315469757713;
Thu, 08 Sep 2011 01:15:57 -0700 (PDT)
Received: from [10.1.1.50] (155.88-67-202.dynamic.dsl.syd.iprimus.net.au
[202.67.88.155])
by mx.google.com with ESMTPS id 11sm4561404ani.11.2011.09.08.01.15.54
(version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 01:15:56 -0700 (PDT)
Message-ID: <4E6879B6.7090203@gmail.com>
Date: Thu, 08 Sep 2011 18:15:50 +1000
From: Steve <shadders.del@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
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.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(shadders.del[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R1ZmF-0003Id-78
Subject: Re: [Bitcoin-development] bitcoind multiplexing proxy -
request/response routing problem
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shadders.del@gmail.com
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: Thu, 08 Sep 2011 08:16:04 -0000
4a/ Serialize all request/response exchanges. i.e. request comes in
from remote node, proxy aquires lock on the proxy-localdaemon channel
and sends request. Channel remains locked until response is received or
timeout (in which case remote node gets no response). Unlock channel
after response received and send to client.
Possibly messages that don't expect a response (e.g. relaying a tx
broadcast from remote node) can be pushed down a locked channel to
improve performance as they won't interfere with sequencing. Locked
channels may also receive other unsolicited messages from local daemon
before the expected response message which would be dealt with the same
as if they came from an unlocked channel.
Disadvantages: Idle time for channel while waiting for response. As
per option 2 this allows the proxy to stay dumb/thin but loses
opportunity for de-duplicating/caching unless option 1 is layered on top.
4b/ As per 4a but use all 125 available bitcoind connections in a
channel pool. Acquiring a lock on a channel consists of checking for an
unlocked channel first then waiting in a queue for one to become available.
|
