Re: [decentralization] RE: p2p working group/standards
- Tony Kimball wrote:
>Yes, I agree, using port 80 makes things easy. The problem I
> .......... ... ...... .. ;)
> Only where interoperability is a concern, however. And BXXP is
> transport, which brings us to...
> coderman@..., who pronounced:
> : It is a datagram transport running atop UDP/IP. It
> : provides virtual connection multiplexing, and supports NAT, and reliable
> : transfer, although the default is unreliable.
> Firewall transit is best via http. In the context of standardizing
> common infrastructure, whenever transport dependence is required, I
> have to think that http has got to be a given. But large parts of
> common infrastructure will be transport-independent.
encountered is that for large scale messaging this doesnt work well.
This is where DTCP, or whatever you want to call it, come in. It is for
messaging only, aka like a signalling network, and once the resource you
are searching for has been located, you are free to use any type of
alternative, standard, etc, transport.
For instance, using Alpine/DTCP i may query for a given document. lets
say its an mpeg p2p conference recording. The locators for this
document may include an http:// reference, perhaps a Freenet key, and
perhaps an OpenCOLA identifier. You can then choose which source you
would retrieve the document from.
I readily agree that UDP is not even remotely acceptable for
'transport', however, that is not its intent anyway. I hope to have a
large selection of transport options available in the server once
complete. Swarmcast, Freenet, Publius, etc, all have very attractive
features for transporting data, however, locating the data is the sole
purpose of Alpine/DTCP.
> : This is a messagingOnly in the sense that the game developers have. This will not work for
> : protocol, not a transport protocol (although, it can be used for
> : transport between two NAT peers as the only option)
> Do you claim to have solved the NAT-2-NAT problem in a sufficiently
> general way to be of wide interest?
all NAT routers, however, it does work for the majority. Sometimes you
must perform some added configuration on your NAT router for this to
work. I.e. turning on loose UDP masquerading in the linux kernel.
>True, and you can use TCP over UDP. The main problem here is that it is
> : This is also intended to be a persistant connection protocol, with
> : support for reactivating connections after an IP/port change (due to
> : dial-up, NAT, etc).
> : Feel free to let me of any questions you may have.
> I always thought that TCP/UDP (which is just like TCP/IP, but with an
> extra 8 octet/packet of header, and has portable, free, user-space
> implentations in the wild) would be the way to use UDP NAT transit for
> transport, because it has a well-developed theory and longstanding
> practice with respect to things like congestion control, et filia.
> If you please, I'd like to ask that you consider this suggestion
> against DTCP, and comment to the list, on the basis of your unique
> expertise with DTCP.
usally not worth the effort. DTCP is not a streaming protocol like TCP,
and it is mainly an unreliable protocol. Its sole purpose is to provide
multiplexing for large numbers (100,000+) of concurrent connections,
allow communication through dual NAT configurations, and provide for
persistant transports. (only a small number of packets are reliably
sent. all major operations, broadcasts, etc, are unreliable)
Reliable bulk transfer protocols should be used for transferring
documents, files, etc. This may be TCP over UDP, it may be OpenCOLA, it
may a freenet cache... who knows.
So, to get back to the point, TCP would be overkill for simple
messaging. TCP also supports a comparably small number of concurrent
- Justin Chapweske said:
> ... switch to SHA-1.Probably going to SHA-1 isn't too big of a problem. I'll bring it up with
> The biggest group that I havn't yet talked to about this is the Gnutella
> guys, but I'm sure they'd be into it as well. Any Gnutellians on the
those that I know. Interestingly, there are ways to add file hashes within
the existing protocol specifications - it should even be backwards