I’ve been playing with an idea that would involve running a machine over a delay-tolerant mesh network. The thing is, each packet is precious and needs to be pretty much self contained in that situation, while modern systems assume SSH-like continuous interaction with the user.

Has anyone heard of anything pre-existing that would work here? I figured if anyone would know about situations where each character is expensive, it would be you folks.

  • nickwitha_k (he/him)@lemmy.sdf.org
    link
    fedilink
    arrow-up
    0
    ·
    2 days ago

    As long as you’re using TCP (what SSH uses) or a similar protocol, you should be able to deal with a situation like that. You’d mainly need to ensure that your client and server are tuned to meet your needs. With TCP, every packet is considered important and if the receiver does not acknowledge receipt, the sender will resend.

    • CanadaPlus@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      1 day ago

      I’m not talking a lot of latency, I’m talking snail-mail levels. Hours probably won’t even be unusual, because hops will happen partly by sneakers net as people move around with their nodes. The concept is distributed burst radio for extreme censorship environments.

      The point of the containers in the first place is to make as much as possible work offline, without the user having to be in the loop.

      • nickwitha_k (he/him)@lemmy.sdf.org
        link
        fedilink
        arrow-up
        0
        ·
        1 day ago

        Oh that’s interesting. I might suggest looking at implementations of IP Over Avian Carrier (IPoAC). And I do mean that seriously. The idea started as an April Fools RFC but some people have actually implemented it. Basically, just using a different physical layer.

        • CanadaPlus@lemmy.sdf.orgOP
          link
          fedilink
          arrow-up
          0
          ·
          12 hours ago

          Yeah, that’s probably worth a look. Good suggestion. There’s also delay-tolerant protocols for space and similar, but I don’t know if any of them define an endpoint, as opposed to just a transport layer.

          • nickwitha_k (he/him)@lemmy.sdf.org
            link
            fedilink
            arrow-up
            0
            ·
            6 hours ago

            Indeed. I’d really suggest going for something based upon Internet Protocol, with any software that you need at endpoints to read and/or transmit. I might poke about at some ideas on the weekend (long holiday). What languages are you thinking to use?

  • MajorHavoc@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    2 days ago

    The ‘ed’ editor was designed for high latency networks. I would pull on that thread. That is, in your shoes, I would read up on ‘ed’ and related tools.

    • CanadaPlus@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      0
      ·
      1 day ago

      Ed is great (in this context). I think there’s been posts about it on here before. It’s just a text editor, though.

      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        1 day ago

        Yeah. I’ve had mentors regail me of other tools they used alongside ‘Ed’, but I wasn’t listening very attentively. Hopefully that’s something that can be dug out of the history of the Internet.

        I would definitely choose the old reliable stuff over something new and fancy, if I had this use case.

      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        2 days ago

        Delightful!

        “Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user’s disk quota by 100K; and 3) RUNS ED!!!”

        Gave me a giggle. That 100k loss has got to hurt for a user who still tries to run ‘vi’ on a classic system, I imagine.

        Edit:

        Another gem:

        “Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.”

    • CanadaPlus@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      0
      ·
      1 day ago

      Do they post their software somewhere? What they use for space probes is exactly what I would need, but I kind of figured it would be a trade secret.

        • CanadaPlus@lemmy.sdf.orgOP
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          1 day ago

          Yeah, I want not real time. The goal of having containers in the first place is to enable as much as possible without needing to put a human in the loop, since you have no idea how long each packet will spend in transit.

          If I could emulate Curiosity’s onboard computer that would be a decent starting point.

          • CarbonatedPastaSauce@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 day ago

            In that case it might not hurt to reach out to some NASA email addresses. The people who write that stuff are, after all, nerds like us, and would probably be happy to share whatever they are allowed to share.

            It’s funded by taxes so, security issues aside, there shouldn’t be a lot of trade secrets.

            • CanadaPlus@lemmy.sdf.orgOP
              link
              fedilink
              arrow-up
              0
              ·
              1 day ago

              Government agencies, in my experience, tend to believe in security through obscurity; even the ones that don’t worry about spies as much as NASA. That said, maybe it’s worth a shot. I’ll have to figure out who’s the best person to bug.

    • CanadaPlus@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      0
      ·
      1 day ago

      That’s really helpful. Thank you! MOSH might work, I’ll have to play around with it.

      Could you go into more detail about the tmux functions? If it’s a way to write everything to files instead of a STDOUT in a predictable way, that would be great, since each packet could be a (compressed) shell script that explicitly includes which data to send back, if any.

      • MNByChoice@midwest.social
        link
        fedilink
        arrow-up
        0
        ·
        6 hours ago

        No, tmux does not redirect to a file. Though ‘>’ and ‘script’ do.

        Tmux is like ‘screen’ and can be wrapped with ‘byobu’.

        • CanadaPlus@lemmy.sdf.orgOP
          link
          fedilink
          arrow-up
          0
          ·
          2 hours ago

          I mean, I guess you could just programmatically insert a > after every command. That’s actually a pretty good idea. It’s kind of obvious now that you mention it, haha!

          It would be better if the tools expected to be used this way, but as a quick kludge for a project about something else it’s probably sufficient.