From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UJWxK-0002no-CE for bitcoin-development@lists.sourceforge.net; Sat, 23 Mar 2013 22:30:30 +0000 Received: from mail-we0-f174.google.com ([74.125.82.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UJWxI-0003ku-MQ for bitcoin-development@lists.sourceforge.net; Sat, 23 Mar 2013 22:30:30 +0000 Received: by mail-we0-f174.google.com with SMTP id u7so218749wey.19 for ; Sat, 23 Mar 2013 15:30:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2HqNZRSU5UfsNWvz3Ya4Mk6Dogq+fpBeePkIdBTnPqM=; b=B7sNYbTuWI/KWpfk1mzskNDbW5FDVPuit/3AKjKhQJGY/SfP1AQmc4gQ9g3nhbWn7Q X3HOfaYjdh6IAj7VqAXoo1gTbLPIDAyvuFYCm3bFh5BTqA9iyDCovJfDH0aMxvgvZF8l cTAsn3O/2RUWCqZ2TtVaKtDruLy4Gm7PRypSSPDZoj6iePM9QVKs3TX1ReT2qBr/wmj0 87Xm3IEfcPTKxQs+6TOkC9hqr0CMq0aAzlmZm/JdvkWmgPMFDp4raPkAawEMqZmsy8zP lFeqpPwuNWDXFigcmUGQFzJstUWQmMSktjGMTBSLRCrx6ViugzzNjNKbfj6ud+jzz+OV XB8Q== MIME-Version: 1.0 X-Received: by 10.180.182.36 with SMTP id eb4mr11894443wic.8.1364077822181; Sat, 23 Mar 2013 15:30:22 -0700 (PDT) Received: by 10.194.30.38 with HTTP; Sat, 23 Mar 2013 15:30:22 -0700 (PDT) X-Originating-IP: [50.0.36.186] In-Reply-To: References: Date: Sat, 23 Mar 2013 15:30:22 -0700 Message-ID: From: Mark Friedenbach To: Jeff Garzik Content-Type: multipart/alternative; boundary=047d7b6229260995d304d89f1e68 X-Gm-Message-State: ALoCoQlNVrzpLslY+jjV4fxzplt/UHF+0FaG/2RfCY1HXfaFfyICJXoH7/+M19B/4ouWQBDc9tqL X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1UJWxI-0003ku-MQ Cc: Bitcoin Development Subject: Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 22:30:30 -0000 --047d7b6229260995d304d89f1e68 Content-Type: text/plain; charset=UTF-8 If you're considering a datagram protocol, you might be interested in some more modern alternatives to UDP: UDT: Breaking the Data Transfer Bottleneck http://udt.sourceforge.net/ Stream Control Transmission Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol On Sat, Mar 23, 2013 at 12:17 AM, Jeff Garzik wrote: > Here is a rough draft implementation of a UDP P2P protocol extension > for bitcoin: > > https://github.com/jgarzik/bitcoin/tree/udp > http://yyz.us/bitcoin/udp-v0.patch > > Protocol specification (such that it is): > > - UDP, bound to same port as TCP P2P (normally 8333) > - Active, simultaneous TCP P2P connection required (useful against DoS > and other attacks) > - Same message format as TCP P2P, same pchMessageStart conventions, > etc. (my CNetMessage pull req would be helpful here) > - Multiple P2P messages per UDP packet permitted > - Max UDP packet size 100*1024 bytes > - Advertises NODE_UDP in nServices > - New "getudpcook" TCP P2P command returns a "udpcook" message, > containing a yummy cookie > - UDP P2P commands "inv", "tx" and "addr" are handled as if received via > TCP > - UDP P2P command "udpsub" sets a mask, that subscribes to one or more > data broadcasts. > - When USM_INV_BCAST mask bit is set, receive "inv" messages via UDP > rather than TCP. > > Project and design goals (or, why do this?): > > - It is theorized that UDP may be useful for some messages we > broadcast throughout the network > - A productive discussion STARTS with code, otherwise discussion > continues forever. > - Investigate improving "inv" relay speed > - Investigate unconditional "tx" broadcasting via UDP, as "inv" > alternative, for small tx's. > - Investigate improving block relay speed (or perhaps block header relay > speed) > - Open up new design avenues, for P2P patterns more suited to UDP than > TCP in general. > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti.com > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7b6229260995d304d89f1e68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you're considering a datagram protocol, you might b= e interested in some more modern alternatives to UDP:

UDT: Breaking = the Data Transfer Bottleneck
htt= p://udt.sourceforge.net/

Stream Control Transmission Protocol
http://en.wikipedia.org/wiki= /Stream_Control_Transmission_Protocol



On Sat, Mar 23, 2013 at 12:17 AM, Jeff G= arzik <jgarzik@exmulti.com> wrote:
Here is a rough draft implementation of a UDP P2P protocol extension
for bitcoin:

=C2=A0 =C2=A0 =C2=A0https://github.com/jgarzik/bitcoin/tree/udp
=C2=A0 =C2=A0 =C2=A0http://yyz.us/bitcoin/udp-v0.patch

Protocol specification (such that it is):

- UDP, bound to same port as TCP P2P (normally 8333)
- Active, simultaneous TCP P2P connection required (useful against DoS
and other attacks)
- Same message format as TCP P2P, same pchMessageStart conventions,
etc. (my CNetMessage pull req would be helpful here)
- Multiple P2P messages per UDP packet permitted
- Max UDP packet size 100*1024 bytes
- Advertises NODE_UDP in nServices
- New "getudpcook" TCP P2P command returns a "udpcook" = message,
containing a yummy cookie
- UDP P2P commands "inv", "tx" and "addr" are= handled as if received via TCP
- UDP P2P command "udpsub" sets a mask, that subscribes to one or= more
data broadcasts.
- When USM_INV_BCAST mask bit is set, receive "inv" messages via = UDP
rather than TCP.

Project and design goals (or, why do this?):

- It is theorized that UDP may be useful for some messages we
broadcast throughout the network
- A productive discussion STARTS with code, otherwise discussion
continues forever.
- Investigate improving "inv" relay speed
- Investigate unconditional "tx" broadcasting via UDP, as "i= nv"
alternative, for small tx's.
- Investigate improving block relay speed (or perhaps block header relay sp= eed)
- Open up new design avenues, for P2P patterns more suited to UDP than
TCP in general.

--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

---------------------------------------------------------------------------= ---
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.s= f.net/sfu/appdyn_d2d_mar
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--047d7b6229260995d304d89f1e68--