Ice:: 一直不敢用Bidirectional的双向调用
为了解决公共网络与私有网络的穿透问题,Ice提出了在单个tcp连接上的双向传输方式
一直以来对于Server端主动发送Rpc请求到Client端的应用我就一直很小心的使用bidirection方式,甚至是彻底不用,
因为通过验证发觉要使用bid则必须关闭ACM管理,也就意味着这个tcp连接是个长连接,只有在这个长连接上server才能
发起对客户端的rpc调用,但如果连接断了呢,client到server的rpc请求很简单,ice会重新发起连接,但之后的server到client的
rpc请求就不行了,这样必须要求client再次初始化bid操作:
所以这个咚咚我个人觉得是鸡肋,不知大家如何看同
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).
一直以来对于Server端主动发送Rpc请求到Client端的应用我就一直很小心的使用bidirection方式,甚至是彻底不用,
因为通过验证发觉要使用bid则必须关闭ACM管理,也就意味着这个tcp连接是个长连接,只有在这个长连接上server才能
发起对客户端的rpc调用,但如果连接断了呢,client到server的rpc请求很简单,ice会重新发起连接,但之后的server到client的
rpc请求就不行了,这样必须要求client再次初始化bid操作:
1
proxy
->
ice_getConnection()
->
setAdapter(adapter);
2 proxy -> addClient(ident);
这个也太可怕了,Ice是不要求客户直接管理底层的通信连接细节的,所以客户不容易知道是否被重新连接
2 proxy -> addClient(ident);
所以这个咚咚我个人觉得是鸡肋,不知大家如何看同
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).