Hacker News new | past | comments | ask | show | jobs | submit login

What's the use case for this?



Since quic sessions can be tracked by the connection id rather than the srcip/dstip/sport/dport/ipproto 5-tuple you could switch networks and have your session survive. Not sure if this implementation achieves that or not though.


Wait, can one checkpoint/restore QUIC connections easily these days? Which implementations/libraries allow that?


libquic should support it, but I'm not sure about how widely this is supported on servers. It should be supported on nginx at least.


Since browsers implement QUIC, probably you can run SSH over QUIC on a web browser, making it possible to run ssh client on unconventional platforms that have a browser.


Browser apps can't use raw QUIC, they can use HTTP (including HTTP3).

Just like browser apps can't use TCP.


Unconventional platforms usually get SSH years before browser supporting QUIC.


I think the lack of head of line blocking could be useful for SSH session multiplexing when using it as an ad hoc VPN.


It looks like the multiplexed SSH channels are in a single QUIC stream, so it doesn't help with head-of-line blocking? Honestly not sure what it does from reading the README.


Apparently SSH over UDP with much less code and configuration compared to Mosh.


> Apparently SSH over UDP with much less code and configuration compared to Mosh.

What configuration? I'm trying to assume best intent but have you ever used mosh? It has zero configuration. That's the whole point.


Last time I installed Mosh (on Ubuntu) I just installed the package & did not need to do any configuration. It just worked.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: