4 ms·

It'd be cool to have the ability to pipe stuff over the Internet from shell in real time like you would with SSH for instance. So I could do: A$ curl --upload-

by oxplot 11y ago

It'd be cool to have the ability to pipe stuff over the Internet from shell in real time like you would with SSH for instance. So I could do: A$ curl --upload-file - http://blah http://blah < /proc/kmsg B$ curl http://blah/uYsfVX http://blah/uYsfVX and see live stream of data on B.

javajosh 11y ago
That would be cool, but the devil is in the details. For one thing, does the "upload" wait for at least one "download" to connect? Or does "upload" go to a cache that is re-used for all subsequent downloads? What are the timeouts? E.g. how long would blah.com hold the upload connection open until (at least one) download opened up? The other thing that makes it less cool is that it's a hack that would be better off not existing. The ideal case is that every device should have a unique ID, such that we can directly "subscribe" to anything on any device without using an intermediary (well, an application level intermediary anyway; you'll always be using link-level intermediaries). Such an ID might be IPv6, in which case such a service is trivially replaced with ordinary every day ssh/scp.
- oxplot 11y ago
  I think it should be as dumb and simple as possible and do nothing deviating from normal unix behavior (ie pipe). So it would cache only one chunk of data sent by A and start streaming to the first download request.
lmm 11y ago
You can use netcat for that. Or Bash has built-in TCP support.
Retr0spectrum 11y ago
You can do that with netcat if either A or B are listening.
- Symbiote 11y ago
  I do this fairly regularly. A$ tar cv * | nc -l -p 1234 B$ nc a.example.net 1234 | tar xv Or I might remove a 'v' and pipe through 'pv' to see the transfer rate and amount.
- oxplot 11y ago
  Well over the "Internet" kind of implies behind a firewall so the service would be a convenience to avoid setting up port forwarding etc.
  - lolidaisuki 11y ago
    VPN are a thing. I recommend just installing cjdns and forwarding the home end. It also encrypts your traffic. You wouldn't want to netcat in cleartext over the internet.
    - voltagex_ 11y ago
      You could always just pipe it through ssh or some other thing. Setting up openvpn or similar is nontrivial - even if you're lucky enough to have a static IP and enough spare time to make it work.
      - lolidaisuki 11y ago
        > Setting up openvpn or similar is nontrivial Setting up cjdns is less work than setting up SSH.
gbin 11y ago
It reminds me of that: http://klaig.blogspot.com/2012/08/skypipe-cloud-based-namepipe.html?m=1 http://klaig.blogspot.com/2012/08/skypipe-cloud-based-namepi...
zackboe 11y ago
Someone else in this thread mentioned chunk.io which offers this http://chunk.io/#stream_content_beta http://chunk.io/#stream_content_beta

by oxplot 11y ago

javajosh 11y ago

That would be cool, but the devil is in the details. For one thing, does the "upload" wait for at least one "download" to connect? Or does "upload" go to a cache that is re-used for all subsequent downloads? What are the timeouts? E.g. how long would blah.com hold the upload connection open until (at least one) download opened up? The other thing that makes it less cool is that it's a hack that would be better off not existing. The ideal case is that every device should have a unique ID, such that we can directly "subscribe" to anything on any device without using an intermediary (well, an application level intermediary anyway; you'll always be using link-level intermediaries). Such an ID might be IPv6, in which case such a service is trivially replaced with ordinary every day ssh/scp.

oxplot 11y ago
I think it should be as dumb and simple as possible and do nothing deviating from normal unix behavior (ie pipe). So it would cache only one chunk of data sent by A and start streaming to the first download request.

lmm 11y ago

You can use netcat for that. Or Bash has built-in TCP support.

Retr0spectrum 11y ago

You can do that with netcat if either A or B are listening.

Symbiote 11y ago
I do this fairly regularly. A$ tar cv * | nc -l -p 1234 B$ nc a.example.net 1234 | tar xv Or I might remove a 'v' and pipe through 'pv' to see the transfer rate and amount.
oxplot 11y ago
Well over the "Internet" kind of implies behind a firewall so the service would be a convenience to avoid setting up port forwarding etc.
- lolidaisuki 11y ago
  VPN are a thing. I recommend just installing cjdns and forwarding the home end. It also encrypts your traffic. You wouldn't want to netcat in cleartext over the internet.
  - voltagex_ 11y ago
    You could always just pipe it through ssh or some other thing. Setting up openvpn or similar is nontrivial - even if you're lucky enough to have a static IP and enough spare time to make it work.
    - lolidaisuki 11y ago
      > Setting up openvpn or similar is nontrivial Setting up cjdns is less work than setting up SSH.

gbin 11y ago

It reminds me of that: http://klaig.blogspot.com/2012/08/skypipe-cloud-based-namepipe.html?m=1 http://klaig.blogspot.com/2012/08/skypipe-cloud-based-namepi...

zackboe 11y ago

Someone else in this thread mentioned chunk.io which offers this http://chunk.io/#stream_content_beta http://chunk.io/#stream_content_beta