hakvroot

I found that at least one "local" Google is also introducing an innovative new concept today. Google Netherlands : https://www.youtube.com/watch?v=LSZPNwZex9s

Any more from Google <your country here>?

Thank you! And I'd be happy to elaborate a bit more, although you already explained most of it yourself ;). Currently the server just stops reading from the socket and the rest is being handled by the networking stack (i.e. buffer fills up, window size is to 0). At this moment the buffer size is also fixed (it sits somewhere between having good throughput and not consuming too much memory for parked connections), but an improvement would be to change it dynamically to improve behavior on both fronts.

For any other versions or source releases I'll post an update!

Thanks! I made some comments regarding to open sourcing it in reply to vortico (this thread) - current status is contemplating.

Currently I haven't licensed the backend as free software; the primary reason for this is that I reuse quite a lot of components from a different project of mine (https://gemin.ee) and I haven't decided yet on whether I want to release those components or remove them as dependencies. Since I too am familiar with useful stuff suddenly disappearing I'll give you my word that I will release the source if I have to shut down. If I decide to share the source I'll post a link to it on the site itself, so you won't have to look for it ;).

On another note, I'd encourage you to write a streaming download service. Compared to file uploading - storing - downloading I found it fun to do but also quite non-trivial to accomplish. I am planning to have another go at it myself, but with a different language (Go, Pony or Elixir). When run alongside of each other with the same UI/frontend/api it would make a nice benchmarking mechanism :).

Thank you, and of course you may.

The backend is written in Java(8) and it is built with the following (noteworthy) components :

  Netty[1] - Extremely fast and stable Java networking framework,
             serves static files and relays traffic 
             (both tasks are custom implementations)

  Guice[2] - IoC container by Google, nice for keeping the code clean

  jOOQ[3] - I log some statistics in PostgreSQL 
            (file size, content type, transfer time - but no filenames). 
            If you're comfortable with SQL jOOQ is a real breeze to use.

The backend is hosted on the cheapest VM option at Digital Ocean (Amsterdam region), (which seems to be holding up pretty well so far :). I do run PostgreSQL on another $5 VM, so the Station307 server only has to worry about serving static content and moving large chunks of bytes around. SSL certificates are kindly provided by Let's Encrypt[4].

For the frontend, I know for a fact it uses left-pad (babel-core)... Written in JavaScript (ES2015 + JSX) and built with :

  Mithril[5] - Fast, small and simple React-like framework, quite a joy to use.

  Bootstrap[6] - Because not having to worry about L&F is quite nice. 
                 Trimmed it down a bit by only importing the parts I needed (SCSS).

And I think that's about it. If there's anything else you'd like to know, let me know!

  [1] http://netty.io
  [2] https://github.com/google/guice
  [3] http://www.jooq.org
  [4] https://letsencrypt.org
  [5] http://mithril.js.org
  [6] https://getbootstrap.com

edit: formatting D:

Author here! This is a little side project I created because I found myself using scp + email to send a file from a server to someone sitting right next to me more than once. I have a different project which does relaying over HTTP so I figured it might be a good idea to reuse a part of the codebase for a simple file streaming service. I finished it yesterday and it already proved useful for myself, and I hope it also proves to be useful for you.

If there are any (more) questions on the what or how, I'm happy to answer them. The day here is however coming to an end so it might take me a couple of hours. While I'm gone, please be aware that the service is running on a $5/month VM ;).

That's exactly what's going on. In a bit more detail: when a POST arrives and no receiver is available yet the server lets the sender know that it won't handle any more data (TCP Zero Window). When the receiver connects to the server the server asks the sender to continue writing and the data is relayed (proxied) from sender to receiver. If multiple receivers connect they're put into a queue and the server waits for the sender to POST the data again once the ongoing transfer is finished.

An interesting difference is that in the browser the rePOSTing is done through scripting whereas when using cURL or Wget (or httpie, or ...) the server will issue a 307 Temporary Redirect allowing cURL/Wget to send the file again without manual intervention. Hence the name! (although that doesn't really account for the "Station" part yet)

Thank you! And thanks for linking to the thread as well; I did already come across it but it definitely contains some good discussion on general feasibility, DCMA issues and other similar projects. It was also nice to learn that transfer.sh is also made in Holland :).

Thanks! I don't have any plans to monetize this to be honest. I built this because I had the need for this myself and, if people like it, it will be a nice exercise in maintaining something that works well under stress :).

geminee - https://gemin.ee

Simple file sharing between devices that don't have to be in the same network. Awesome because it (should :o) work on pretty much any device with a somewhat recent browser.

Very much the same (also as daodedickinson wrote), and I hope I didn't send you on a (short) wild-goose chase with this. I was pleasantly surprised to see that the author took resizing / zooming the window into account and I thought it gave some nice insight on how the features of the pixel art change with scale (without the canvas actually visually shrinking).

Besides moving your mouse around, zooming in and out also works beautifully (might put a bit of a strain on your system though).

Given the sheer amount of work for one piece, with The Three Graeae appearing to be around 1000 lines of code, I'm also quite amazed he managed to produce seven. Brilliant, and Art indeed.

Author (and long time HN lurker) here! First time showing this to a bigger audience and would love to hear (read) your feedback. Besides the web app I've also got an about page which kinda explains how to use it (at https://about.gemin.ee ). Thanks!