Loading ...
Sorry, an error occurred while loading the content.

Re: [decentralization] RE: p2p working group/standards

Expand Messages
  • coder
    ... Yes, I agree, using port 80 makes things easy. The problem I encountered is that for large scale messaging this doesnt work well. This is where DTCP, or
    Message 1 of 55 , Feb 13 9:38 PM
    • 0 Attachment
      Tony Kimball wrote:
      >
      > .......... ... ...... .. ;)
      >
      > 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.


      Yes, I agree, using port 80 makes things easy. The problem I
      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 messaging
      > : 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?


      Only in the sense that the game developers have. This will not work for
      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.


      >
      > : 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.


      True, and you can use TCP over UDP. The main problem here is that it is
      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
      connections (64k).
    • Ben Houston
      ... Probably going to SHA-1 isn t too big of a problem. I ll bring it up with those that I know. Interestingly, there are ways to add file hashes within the
      Message 55 of 55 , Feb 20 1:37 AM
      • 0 Attachment
        Justin Chapweske said:
        > ... switch to SHA-1.
        >
        > 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
        > list?

        Probably going to SHA-1 isn't too big of a problem. I'll bring it up with
        those that I know. Interestingly, there are ways to add file hashes within
        the existing protocol specifications - it should even be backwards
        compatible.

        Cheers,
        -ben houston
        http://www.exocortex.org/~ben
      Your message has been successfully submitted and would be delivered to recipients shortly.