Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jonathan de Jong
    @ShadowJonathan
    That's the point I'm going with
    Kevin Mai-Husan Chia
    @mhchia
    hmm okay
    Jonathan de Jong
    @ShadowJonathan
    Yamux might indeed provide YamuxStream (or similar), but that class doesn't need to know that it's multiplexer is yamux specifically (unless it needs custom behaviour)
    I'm currently giving the entire spec document a read, though, and I already have a feeling that it'll shake some of my previously-established opinions on how to handle this
    Kevin Mai-Husan Chia
    @mhchia

    YamuxStream (or similar)

    So does Mplex

    I think we can just enforce IMultiplexer, which wraps all YamuxMultiplexer and YamuxStream logics inside
    And IStream send/receive messages through some kind of abstracted channels, multiplexer-agnostic

    I'm currently giving the entire spec document a read

    Cool

    And IStream send/receive messages through some kind of abstracted channels, multiplexer-agnostic

    At least I think this one is applicable.

    Jonathan de Jong
    @ShadowJonathan
    Yes
    So basically what this document is mentioning (native transport multiplexing) can just be a class that both inpliments IConnection and IMultiplexer at the same time
    IStream is essentially IConnection, with the write, read, and closes going to the multiplexer instead of the underlying transport
    For example, the persistent metadata component could automatically add peer ids and addresses to its registry whenever a new peer connects, or a DHT module could update its routing tables when a connection is terminated.
    To support this, it's recommended that libp2p implementations support a notification or event delivery system that can inform interested parties about connection lifecycle events.
    Kevin Mai-Husan Chia
    @mhchia

    IStream is essentially IConnection

    Yes

    Jonathan de Jong
    @ShadowJonathan
    Which IConnection could have in the form of event properties that are set when those events occur
    Or have occurred
    Or another implimentation, that's applicable on the IConnection level
    Also related to connection management, libp2p has recently added support for QUIC, a transport protocol layered on UDP that can resume sessions with much lower overhead than killing and re-establishing a TCP connection. As QUIC and other "connectionless" transports become more widespread, we want to take advantage of this behavior where possible and integrate lightweight session resumption into the connection manager.
    Ah
    Yeah, then I think I'll reintroduce IConnection as a specific interface, and instead put ISession or something underneath
    Hmmm, I'll have to think about that though
    Yes, IMultiplexer needs an underlying ISession, which IConnection inpliments to its raw transport
    If a transport falls away, the ISession would have to hold up writes and reads till it has gotten a new IConnection
    Jonathan de Jong
    @ShadowJonathan
    IConnection is just an ISession that has an underlying transport, ISession on its own is just a redirector to an IConnection for this current peer it's connected to
    Though then again, QUIC can be implimented at the IConnection level, since it doesn't subclass to a transport...
    Yeah nvm, no ISession, only a custom ResumableConnection or similar for resumable transports like quic
    Or even just a protocol 🤔
    But yeah, after reading that document, I think that specific things like the MultiStream protocol falls completely out of this diagram
    And can instead be attributed next to INetwork (or maybe in/with "IStrategy")
    Kevin Mai-Husan Chia
    @mhchia
    By "can resume sessions", I think it's just built in the transport? So IConnection shouldn't know those details?
    I mean
    Jonathan de Jong
    @ShadowJonathan
    (IStrategy so initial protocol negotiation and upgrades can be swapped out in the future)
    Yeah, that's why I had a derp moment
    Kevin Mai-Husan Chia
    @mhchia
    the resume things should only live in QUICTransport, just like TCPTransport.
    yeah
    Jonathan de Jong
    @ShadowJonathan
    Or maybe even on a protocol level
    Resumable connections make me excited, though
    Kevin Mai-Husan Chia
    @mhchia
    What do you mean by protocol level? You mean the protocol in libp2p?
    Jonathan de Jong
    @ShadowJonathan
    It means that nodes can't be stayed fixed to just one network, and instead can move out and about while staying connected to possibly multiple networks at once, while protocol traffic stays interrupted
    That'll be a huge benefit
    Yes, protocols in libp2p
    Not transport protocols (like ip4, ip6, dns, p2p-circuit, etc.)
    Maybe even provide a dummy IResumableConnection in the abc module so application code can see if the underlying connection is resumable, though this is superficial and only applicable in very specific use-cases
    Kevin Mai-Husan Chia
    @mhchia
    Hmm I'd think it's more appropriate to have transport configurable at runtime. I mean, when listen and dialing we specify what transport we want
    Jonathan de Jong
    @ShadowJonathan
    I haven't touched transports yet, only everything that's working above that
    Kevin Mai-Husan Chia
    @mhchia
    ah
    Jonathan de Jong
    @ShadowJonathan
    I'm currently just trying to figure out how to impliment this as compact and lightweight as possible in the abc library
    Kevin Mai-Husan Chia
    @mhchia
    i mean, you mentioned that we support quic as a protocol in libp2p, right?
    Jonathan de Jong
    @ShadowJonathan
    Yes
    TCP, udp, others