Network connection establish

1.在会话连接后如发生网络故障，连接断开后是否tuxedo能够自动恢复连接？
2.在使用会话通讯中，通讯双方一方接必然一方收，是否通讯便只能同步处理，客户端发一条请求，通讯控制就交给服务端，客户端就无法向SERVER提交新的请求直到服务端处理完反馈给客户端，把会话控制交回。
3.tuxedo长联方式中只有会话一种吗？
不好意思，又问低级问题

------------------------------------------------------------
好象一点都不低级呀，这些问题:-)
------------------------------------------------------------
1. TUXEDO/WS客户端在建立和服务端的连接时，首先发送请求到WSL，WSL按照负载均衡算法，挑一个比较闲的WSH的端口号，送回。客户端于是断开与WSL的连接，然后发送SOCKET连接请求给WSH。即一个tpinit()有两次TCP建链动作。
2. WSH接到客户端请求，就为其在共享内存中建立上下文，同时在BBL中注册该客户端。这里，WSH就是WORKSTATION在本地的代理了。
3. TUXEDO的长连接，短连接一般指在一个tpinit()/tpterm()之间是否有多个tpcall()/tpacall()等，即如果建链一次，反复做业务，为长连接；如果每次做业务都要先建链，为短连接。
4. 在TUXEDO的常用函数内部，比如tpcall()都包含了tpinit()代码，在未建链时会自动做初始化动作，但仅限于不含SECURITY的DOMAIN，否则怎么知道该填什么用户名和密码呢？
5. 如果是会话断开，那客户端的上下文也没了，真实情况比较复杂。简单的话，可以理解为不能自动重连。
6. 会话中，可以不把控制权交出去，可以在tpsend()中设置FLAG，让它SEND_ONLY.
7. 由于TUXEDO的SERVICE是无状态的，你所指的长联如果是在一个SERVICE不出来时来回交互，大概会话是最好的实时方法了。如果用广播，时间等等，也可以在一个SERVICE内部执行很多次活动，但不直观。

Fiat兄说得很对,不用tpinit,直接tpcall也是可以的,因为你编译的时候有或者无-w参数已经连接了不同的库了,这样tpcall就知道你 的连接是本地还是WS的,在没有连接的时候,它会先去连接,和tpinit的作用一样的.这个我已经试验过了,效果一样.正如他所说,这个只限于最低的安 全级别的,后3种都不行.

tpinit是一个可选的函数。如果直接使用tpcall或其他API也是可以得

尽管是这样,但是我觉得还是显式的做tpinit是一个好的风格,这样可以及早的发现join application的错误,程序的思路也比较清晰.

同意qiupeng的建议，还是使用tpinit，因为如果网络等有问题，在tpinit就发现了，不会做了什么tpalloc，Fchg32了，到 tpcall才报告网络不通或server有问题等。而且如果使用安全认证的，必须使用tpinit了。