Hi Marc,CCB doesn't do any forwarding of packets other than to inform daemon B that daemon A wants to connect. Then daemon B connects to daemon A. Presumably, A cannot directly initiate a connection to B because B is behind a firewall or NAT.
Since CCB brokers TCP connections, UDP is not supported. All communication from A to B that would normally be UDP in Condor is therefore automatically switched to use TCP. In environments where STUN works, we could avoid the overhead of TCP and continue to use UDP. However, we have observed a lot of environments where STUN doesn't work and we haven't been aware of any big problems caused by the use of TCP in place of UDP. If you find some, please let us know!
--Dan Marc Tardif wrote:
Hi folks, I've been reading about the Condor Connection Broker (CCB) and my understanding is that it provides a central point where two services, like the scheduler and the starter for example, can exchange packets if they are both behind firewalls. So, I was wondering if Condor also considered using STUN [1] to achieve the same objective while having the above mentionned "central point" incur significantly less bandwidth overhead. The only difference with this approach is that it only works with UDP, whereas CCB could also work with TCP. However, since Condor already has the concept of a SafeSock, then this could potentially work, right? 1. http://en.wikipedia.org/wiki/STUN