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

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.

Well over the "Internet" kind of implies behind a firewall so the service would be a convenience to avoid setting up port forwarding etc.

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.

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.

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

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.

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.

It reminds me of that: http://klaig.blogspot.com/2012/08/skypipe-cloud-based-namepi...

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