bbcp doesn't work so well for some reason. Where I used to work we had a senior dev that claimed that he could just repurpose bbcp for this. Then he gave up and wrote something custom in c++. Then he rewrote it in go, but used (among other things) non-multithreadsafe primitives, then when asked to make it encrypted, he used epoll with tls (which is apparently not a thing in go? I don't know). I told him he should just use DTLS or hell even a one-time-pad encrypted UDP stream with backpressure management, but he didn't listen to me. Then he rewrote it in C++ again and then went back to the go version. When I left the company, it still wasn't working.

Also, this senior dev never wrote unit tests.

On the other hand, maybe bbcp will work, and the senior dev just didn't know what he was doing. There was another senior dev who, seeing what was coming down the pike, left his job, and on his way out he was like, "yeah you can do it with bbcp, just you gotta tweak your tcp congestion rules on all the hops (which we could do, but is probably not an option for OP)"

>On the other hand, maybe bbcp will work, and the senior dev just didn't know what he was doing

I mean... based on your description it sure sounds like he didn't know what he was doing.

Well yeah but the competent dev would have told you that it wouldn't work for OP.

The other senior dev was pretty close. We support bbcp for transfers to/from some of our environments, but we don't do the tuning. Instead, we set things up to be as accessible as possible (jumbo frames enabled, minimum # of hops from the DTN to the border), and leave it to the user to set all the bbcp options.

Did I miss something or bbcp seems a bit abandoned to itself?