In the traditional Berkeley socket system, a connection is always made from a client to a server. In a TCP connection setup, for example, the first SYN packet always traverses from the client, who calls connect, to the server, who calls listen and accept. We may say that, in the Berkeley socket system, the direction of a connection is tightly coupled with the role--who the client/server is--in the communication.
The main idea of GCB is decoupling the decision on what direction a connection must be made from who the client/server is. In GCB, the direction of a connection, i.e. the direction that the first SYN packet flows, is determined based on the relative network situation of communicating parties. Therefore, a connection can be made either (1) from a client to a server, (2) from a server to a client, or (3) from both a client and a server to a rendezvous point. If client machine cannot talk to the server machine but the server can talk to the client--likely the case that the client is in the public network and the server is inside private network or behind a firewall, then the connection is made from the server to the client. On the other hand, if neither can directly talk to the other--likely the case that parties are in different private or firewalled networks, then the connection is made through a relay point in the public network.
Decoupling the direction from the role means that applications should decide their roles in a communication solely based on their semantics and should not worry about in what direction a connection will be made. Implemented as a middle layer between application and Berkeley socket layer, GCB arranges the direction of connections without applications' notice. GCB hides from the application the fact that a connection is made in the opposite direction or through a relay point by doing all the necessary translations between GCB calls issued by the application and regular socket calls.
