Right now, any client that wants to leverage a build farm needs to have a network connection to all worker daemons it wants to use, not just to the scheduler. (Correct me if I'm wrong.)
This makes it impossible to make a build farm in a star topology, where each node (worker and/or client) only has a network connection to the scheduler. This, however, might be useful in some remoting/VPN/tunneling scenarios. See also: #540
I propose an idea where a worker, upon failing to connect to an assigned worker daemon directly, would then make an attempt to do this through the scheduler, which it obviously can access, as a fallback.
In this case, the scheduler would act as a proxy between the client and the worker, passing the assignment and the result of each job there and back.
This would significantly increase the load on the scheduler machine (especially the network bandwidth used), but would make icecc work better in some more exotic networking scenarios, where not all participants are necessarily in the same subnet.
What do you think, is this something you would accept?
As an alternative, an overlay network of a single subnet on top of the spokes of the star topology could be set up with some kind of additional IP tunneling, but it would be nice if that wasn't necessary.
Right now, any client that wants to leverage a build farm needs to have a network connection to all worker daemons it wants to use, not just to the scheduler. (Correct me if I'm wrong.)
This makes it impossible to make a build farm in a star topology, where each node (worker and/or client) only has a network connection to the scheduler. This, however, might be useful in some remoting/VPN/tunneling scenarios. See also: #540
I propose an idea where a worker, upon failing to connect to an assigned worker daemon directly, would then make an attempt to do this through the scheduler, which it obviously can access, as a fallback.
In this case, the scheduler would act as a proxy between the client and the worker, passing the assignment and the result of each job there and back.
This would significantly increase the load on the scheduler machine (especially the network bandwidth used), but would make icecc work better in some more exotic networking scenarios, where not all participants are necessarily in the same subnet.
What do you think, is this something you would accept?
As an alternative, an overlay network of a single subnet on top of the spokes of the star topology could be set up with some kind of additional IP tunneling, but it would be nice if that wasn't necessary.