為了解決公共網(wǎng)絡與私有網(wǎng)絡的穿透問題，Ice提出了在單個tcp連接上的雙向傳輸方式
一直以來對于Server端主動發(fā)送Rpc請求到Client端的應用我就一直很小心的使用bidirection方式，甚至是徹底不用，
因為通過驗證發(fā)覺要使用bid則必須關閉ACM管理，也就意味著這個tcp連接是個長連接，只有在這個長連接上server才能
發(fā)起對客戶端的rpc調(diào)用，但如果連接斷了呢，client到server的rpc請求很簡單，ice會重新發(fā)起連接，但之后的server到client的
rpc請求就不行了，這樣必須要求client再次初始化bid操作：
1 proxy->ice_getConnection()->setAdapter(adapter);
2 proxy->addClient(ident);
這個也太可怕了，Ice是不要求客戶直接管理底層的通信連接細節(jié)的，所以客戶不容易知道是否被重新連接
所以這個咚咚我個人覺得是雞肋，不知大家如何看同
Limitations
Bidirectional connections have certain limitations:
• They can only be configured for connection-oriented transports such as TCP and SSL.
1168 Connection Management
• Most proxy factory methods have no effect on a proxy created by a connection’s
createProxy operation. The proxy is bound to an existing connection,
therefore the proxy reflects the connection’s configuration. For example, it is
not possible to change the timeout value of such a proxy. Similarly, it is not
possible to change the proxy’s security configuration: if the incoming connection
is secure, then the proxy must be secure, and cannot be changed to be
insecure. However, it is legal to change between oneway and twoway invocations.
• A connection established from a Glacier2 router to a server is not configured
for bidirectional use. Only the connection from a client to the router is bidirectional.
However, the client must not attempt to manually configure a bidirectional
connection to a router, as this is handled internally by the Ice run time.
• Bidirectional connections are not compatible with active connection management
(see Section 37.4).