3 ms·

About relying on the developer to provide the relay server (this was early 2022): The cost of croc is mostly bandwidth - over 8 terabytes of data is sent every

by pepa65 3y ago

About relying on the developer to provide the relay server (this was early 2022): The cost of croc is mostly bandwidth - over 8 terabytes of data is sent every month through croc! That's amazing to me since I started this project just as a way for me to share files with friends. Four years ago, the public relay server only costed $5/month, but now it is costing me $40-50/month. The higher cost is enabling file transfers for thousands of people all around the world.

joelthelion 3y ago
Isn't it possible to use the relay to initiate a direct connection between the two clients, instead of transferring the data itself?
- gitanovic 3y ago
  It depends on the topology of the clients network, if they are both behind a specific kind of firewall (don't remember the details) no connection can be established from outside When connection is possible, is my understanding that croc connects directly
  - navigate8310 3y ago
    CGNAT
- wakamoleguy 3y ago
  Sometimes. The VoIP world has been dealing with this for years. The process of finding and connecting the clients is called signaling, and that typically requires a shared relay. The signaling can contain information on how the clients can be reached directly. In SIP, typically each client will use a STUN server to discover their public IPs, and a process call ICE allows the clients to iteratively try those candidates until they establish a connection. Based on the NAT settings, it may not be possible, so clients will also include the IP of a relay TURN server. The challenges with Croc here are largely the same, but with data as the media instead of voice or video. (Although, “VoIP” can also handle data in this way. See WebRTC data channels.)
  - joelthelion 3y ago
    > Sometimes I suppose you could try that, and fall back on full data relaying when it doesn't work. Should save a lot of bandwidth. Of course, that might be a lot of work to implement, not saying it's easy!
    - bmgxyz 3y ago
      This blog post[1] may interest you. As you suggested, the workflow seems to be: 1. Try various techniques that might trick the firewalls on both ends to let the connection through. This requires a relay for the initial negotiation only. 2. If (1) fails, then use a relay for everything. [1]: https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/
qrv3w 3y ago
Thanks! The usage has only gone up - now in 2023 the croc public relay has been using 20 TB of bandwidth every month :| I like to write software that runs forever, but this will get difficult to run in the future if usage keeps climbing.

by pepa65 3y ago

joelthelion 3y ago

Isn't it possible to use the relay to initiate a direct connection between the two clients, instead of transferring the data itself?

gitanovic 3y ago
It depends on the topology of the clients network, if they are both behind a specific kind of firewall (don't remember the details) no connection can be established from outside When connection is possible, is my understanding that croc connects directly
- navigate8310 3y ago
  CGNAT
wakamoleguy 3y ago
Sometimes. The VoIP world has been dealing with this for years. The process of finding and connecting the clients is called signaling, and that typically requires a shared relay. The signaling can contain information on how the clients can be reached directly. In SIP, typically each client will use a STUN server to discover their public IPs, and a process call ICE allows the clients to iteratively try those candidates until they establish a connection. Based on the NAT settings, it may not be possible, so clients will also include the IP of a relay TURN server. The challenges with Croc here are largely the same, but with data as the media instead of voice or video. (Although, “VoIP” can also handle data in this way. See WebRTC data channels.)
- joelthelion 3y ago
  > Sometimes I suppose you could try that, and fall back on full data relaying when it doesn't work. Should save a lot of bandwidth. Of course, that might be a lot of work to implement, not saying it's easy!
  - bmgxyz 3y ago
    This blog post[1] may interest you. As you suggested, the workflow seems to be: 1. Try various techniques that might trick the firewalls on both ends to let the connection through. This requires a relay for the initial negotiation only. 2. If (1) fails, then use a relay for everything. [1]: https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/

qrv3w 3y ago

Thanks! The usage has only gone up - now in 2023 the croc public relay has been using 20 TB of bandwidth every month :| I like to write software that runs forever, but this will get difficult to run in the future if usage keeps climbing.