Friday, March 31, 2006
GT4 tutorial

1. Go to tutorial

2. Download tutorial source code from

3. Unzip the source code package to /home/pliu/gt4_tutorial


use bash afterwards

4. Make service GAR file: 
cd /home/pliu/gt4_tutorial
./ \
-d org/globus/examples/services/core/first/ \
-s schema/examples/MathService_instance/Math.wsdl

5. Deploy service

globus-deploy-gar /home/pliu/gt4_tutorial/org_globus_examples_services_core_first.gar

6. Start gt4 container

source $GLOBUS_LOCATION/etc/

globus-start-container -nosec -p 8998

7. Compile client code

source $GLOBUS_LOCATION/etc/
cd /home/pliu/gt4_tutorial
javac \
-classpath ./build/stubs/classes/:$CLASSPATH \

8. Run client

java -classpath ./build/stubs/classes/:$CLASSPATH org.globus.examples.clients.MathService_instance.Client

Current value: 15

Current value: 10


1. You will need to restart the Globus standalone container for the deployment to take effect.

2. After the container is restarted, all the states are gone.

For error messages caused by rft (not Sql Server is installed)

we can un-deploy this service

All the service will have a directory under $GLOBUS_LOCATION/etc
the directory name is the service id.

source $GLOBUS_LOCATION/etc/
globus-undeploy-gar globus_wsrf_rft

Undeploying gar...

Deleting /home/pliu/gt4/etc/globus_wsrf_rft/security-config.xml
Deleting /home/pliu/gt4/etc/globus_wsrf_rft/factory-security-config.xml
Deleting /home/pliu/gt4/etc/globus_wsrf_rft/server-config.wsdd
Deleting /home/pliu/gt4/etc/globus_wsrf_rft/registration.xml
Deleting /home/pliu/gt4/etc/globus_wsrf_rft/jndi-config.xml
Deleting directory /home/pliu/gt4/etc/globus_wsrf_rft
Deleting: /home/pliu/gt4/etc/globus_packages/globus_wsrf_rft/undeploy.xml
Deleting directory /home/pliu/gt4/etc/globus_packages/globus_wsrf_rft

Undeploy successful

gt4, programer guide portal

An approach other than C-- for MCWS

Given the XML schema, Java/C#/C++ provides a schema compiler to generate the correspondent language binding. That is, for a schema instance XML snippet, the schema compiler can generate the code to un-marshal XML into object for the specific language. This is also true for X#.


For example, in X# schema, we define a method call as


    <xs:complexType name="XSharpMethodInvokeStatement">


            <xs:element name="object" type="XSharpExpression" />

            <xs:element name="param" minOccurs="0" maxOccurs="unbounded">



                        <xs:element name="value" type="XSharpExpression" />





        <xs:attribute name="methodName" type="xs:string" />

        <xs:attribute name="isExternal" type="xs:boolean" default="false" />



Then from the schema compiler or provided by us, we can have the correspondent C++ class

class XSharpMethodInvokeStatement



        XSharpExpression m_object;

        XSharpExpression m_params[];

        std::string m_methodName;

        bool m_isExternal;


       // getter and muter

        void setObject(const XSharpExpression &object);

        XSharpExpression getObject();


        void setParams(const XSharpExpression &params[]);

        XSharpExpression[] getParams();


        void setMethodName(const std::string methodName);

        std::string getMethodName();


        void setIsExternal(bool isExternal);

        bool getIsExternal();



//UnMarshalling, from in-memory object to XML or high level languages such as C++/Java/C#

    CppWriter& operator << (CppWriter &o, const XSharpMethodInvokeStatement &methodInvoke);

    CsWriter& operator << (CsWriter &o, const XSharpMethodInvokeStatement &methodInvoke);

    JavaWriter& operator << (JavaWriter &o, const XSharpMethodInvokeStatement &methodInvoke);

    XmlWriter& operator << (XmlWriter& o, const XSharpMethodInvokeStatement &methodInvoke);


 //Marshalling, from XML to in-memory object

XmlReader& operator >> (XmlReader & i, XSharpMethodInvokeStatement &methodInvoke);





Such that, user can manipulate the code generation just like normal XML string.


For example, if user needs to create a method invocation statement, she or he can do


XSharpMethodInvokeStatement mis=new XSharpMethodInvokeStatement();

XSharpExpression obj= new XSharpExpression();





And then simply call “std::cout << mis;”, user can get the X# code.


There is no conflict between this approach and C-- approach.

The comparison between them is listed as following:

  1. In C-- approach, user needs to learn the grammar of C--; in Schema Binding, users need to know the schema.
  2. In C-- approach, user writes mobile code in C--; in Schema Binding, user can choose their favorite language as long as it has the schema binding library in hand.
  3. In C-- approach, user depends on a specific compiler to convert C-- code into X#; in Schema Binding, user needs a schema compiler.
  4. C-- is more readable than the XML generation code as above.
  5. It is much harder to maintain C-- than the X# schema
  6. Schema compiler sounds more comfortable in the Web world than C--


Thursday, March 30, 2006
java servlet talks to applet

GT4, get started, in simple CA mode




For general cluster machines

Use account 'pliu' for example


1. download gt4 core binary



choose Debian Sarge Binary Installer


2. copy it to your local ~/gt4_src

run "tar -xzvf gt4.0.1-ia32_debian_3.1-binary-installer.tar.gz"

cd gt4.0.1-ia32_debian_3.1-binary-installer

setenv GLOBUS_LOCATION  /home/pliu/gt4

./configure --prefix=/home/pliu/gt4


make install



3. run $GLOBUS_LOCATION/setup/globus/setup-simple-ca

 unique subject name =

cn=Globus Simple CA,, ou=GlobusTest, o=Grid


4. The passphrase of the CA certificate will be used only when signing certificates



5. follow the instruction and run

$GLOBUS_LOCATION/setup/globus_simple_ca_d78b7896_setup/setup-gsi -nonroot -default


6. Host Certificates

6.1 create request

$GLOBUS_LOCATION/bin/grid-cert-request -host ''

It will create



    (an empty) $GLOBUS_LOCATION/etc/hostcert.pem

6.2 sign it

$GLOBUS_LOCATION/bin/grid-ca-sign -in $GLOBUS_LOCATION/etc/hostcer

t_request.pem -out $GLOBUS_LOCATION/etc/grid-security/hostsigned.pem


The new signed certificate is at: /home/pliu/.globus/simpleCA//newcerts/01.pem

cp /home/pliu/.globus/simpleCA//newcerts/01.pem  $GLOBUS_LOCATION/etc/grid-security/hostsigned.pem


7. User certificates

7.1 create request with user password


A certificate request and private key is being created.

You will be asked to enter a PEM pass phrase.

This pass phrase is akin to your account password,

and is used to protect your key file.



7.2 sign it

go to ~/.globus and run

$GLOBUS_LOCATION/bin/grid-ca-sign -in usercert_request.pem -out signed.pem


The new signed certificate is at: /home/pliu/.globus/simpleCA//newcerts/02.pem

cp /home/pliu/.globus/simpleCA//newcerts/02.pem /home/pliu/.globus/usercert.pem


8. copy host key and certification to container key


cp $GLOBUS_LOCATION/etc/hostkey.pem $GLOBUS_LOCATION/etc/grid-security/containerkey.pem

cp $GLOBUS_LOCATION/etc/grid-security/hostsigned.pem $GLOBUS_LOCATION/etc/grid-security/containercert.pem



9. add map


$GLOBUS_LOCATION/bin/grid-cert-info -subject


/O=Grid/OU=GlobusTest/ Liu


associate it with users


$GLOBUS_LOCATION/sbin/grid-mapfile-add-entry -f ~/.gridmap -dn "/O=Grid/OU=GlobusTest/ Liu" -ln pliu


10. change default wsrf security settings

vi ../etc/globus_wsrf_core/global_security_descriptor.xml


<?xml version="1.0" encoding="UTF-8"?>

<securityConfig xmlns="">


        <key-file value="/home/pliu/gt4/etc/grid-security/containerkey.pem"/>

        <cert-file value="/home/pliu/gt4/etc/grid-security/containercert.pem"/>


    <gridmap value="/home/pliu/.gridmap"/>




11. start container 

source $GLOBUS_LOCATION/etc/globus-user-env.csh

$GLOBUS_LOCATION/bin/globus-start-container -nonsec


In case the default port 8843 is used, you can specify -p <port>.

trouble shooting for step 10

in bash

strace $GLOBUS_LOCATION/bin/globus-start-container 2>&1 |grep containercert

grep -ri containercert.pem ..

Wednesday, March 29, 2006

Tuesday, March 28, 2006
.NET AppDomain
In ASP.NET web service, use AppDomain to load and unload assembly.

Create the assembly with same name, will get error message " access denied, the file is in use by another process"

use AppDomain to load and unload the assembly.
Assembly itself can not be unload, so we have to create a new AppDomain and in this new AppDomain to run assembly and finally unload the AppDoamin thus the assembly.

Good entry point to find anwsers for .NET problem
and the famous paper
Eric Gunnerson has a good article on that sort of thing:

AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = m_workDir; //put all .DLL there
setup.ApplicationName = "Mcws";
setup.DynamicBase = m_workDir;
setup.ShadowCopyFiles = "true";
setup.ShadowCopyDirectories = m_workDir;

AppDomain appDomain = AppDomain.CreateDomain(
"Mc", null, setup);

object o= appDomain.CreateInstanceAndUnwrap(
getNamespace(moduleName), //CmmCode.Math ==> CmmCode

MethodInfo mi;
Type t = o.GetType();
mi = t.GetMethod(methodName);
retVal.result = mi.Invoke(o,methodParams);
retVal.success = true;
appDomain = null;

FILE_SHARE* in windows

ASP .NET deployment

part 1.
a. DLL hell
b. .NET assembly
c. XCOPY, COPY project, Installshield deployment

different setup editors

Saturday, March 25, 2006
java plugin and applet
Java Plugin
Java Plug-In Technology connects popular browsers such as Internet Explorer, Mozilla, and Firefox to the Java Platform. It enables applets to run in Sun's Java 2 Runtime Environment (JRE), rather than in the browser's Java runtime environment.

How to read, write local files from the applet

gsoap DOM and xsd:anyType
1. In gSoap, xsd:anyType is of type soap_dom_element
2. with gSoap compiler, it is easy to do (de)serialization on C/C++ data structure
--a. set input flag of SOAP to SOAP_DOM_NODE
soap_set_imode(&soap, SOAP_DOM_NODE);
--b. declare the C/C++ data structure in the header file which will be processed by gSoap compiler soapcpp2
typedef float xsd__float;
c. write code to generate the element

int mcws__invokeCode(struct soap* , char *name,
struct mcws__invokeCodeResponse &result)
result.ret = 10;
struct soap soap;
soap_set_imode(&soap, SOAP_DOM_NODE);
xsd__float f = 12.34;
//xsd__float type is available, and the xsi:type attribute is present
//or element tag matches the type name
soap_dom_element retVal(&soap, NULL, "float", &f, SOAP_TYPE_xsd__float);
result.value = retVal;
cout << retVal;
return SOAP_OK;

struct mcws__invokeCodeResponse {
xsd__anyType value;
int ret;

--c. On the other end,we also need to tell gSoap

soap_set_imode(&soap, SOAP_DOM_NODE);
//let gSOAP do C/C++ serialization/de-serialization
struct mcws__invokeCodeResponse retVal;
xsd__float f;
char* name="eval";

if (soap_call_mcws__invokeCode(&soap,
NULL, name, retVal) == SOAP_OK)
soap_dom_iterator walker=retVal.value.find(SOAP_TYPE_xsd__float);
for (;walker!=retVal.value.end();++walker)
//gSOAP will do the magic here
f = *((xsd__float*)(*walker).node);


Tuesday, March 21, 2006
gsoap and apache
Whatever your reason, let's assume you have some code written in C that needs to be called via SOAP. You can either use one of the SOAP frameworks available for Java and use JNI to call it, or else you can set up a native C SOAP environment for your code. The foremost free SOAP solution is the Apache Foundation's Axis. Most people know the Java version, but there is also a full-featured C version available and this is the one we will be working with.

Unfortunately, installing Axis-C++ can be tricky, especially the integration with the Apache web server. The following step-by-step guide will enable you to get a production-level installation up and running quickly on GNU/Linux. After installing the server, the rest of the article will describe the development and deployment of a basic SOAP service.

Monday, March 13, 2006
ACE_String && performance issue

String allocation/deallocation is a primary cause of heap fragmentation and poor performance.


There are three things that we can do to speed up string usage.



const SymString fname="my func";

should be .. static const SymChar fname[]=SymText("my func");


SymString will allocate memory for "my func" and copy it every time the function is entered.



SymString myString = "x";

if (myString == "x") do something;

should be .. if (ACE_OS::strcmp(myString, "x") == 0) do something;


SymString doesn't implement the operator== for a char *. Instead it will copy "x" into another SymString, do the compare and then free it.


Can we add such operator== for char* into ACE_String, so we don't need to look it thru our code? ----------Michael.


SymString myGetFn()


    return m_value;



should be

const SymString & myGetFn() const


    return m_value;



Always return a const reference in a Get fn. It is also a good idea to declare the Get fn as const.



General conclusions:
1. We need task chunking in SDK. - SDK and SSM are both idling waiting for requests.
2. We need to improve the SSM's bind/unbind decision making - when task throughput is slow, it makes it slower.
3. The SSM's critical code path for task acceptance is very efficient.
4. The SDK's code path for task sending may be optimized a bit - it's 4 times slower than the SSM. I couldn't get quantify to run on the SDK.
5. A small improvement can be made in marshalling/communications by putting call objects and message blocks into an object pool.


- Ajith


web services deployment in J2EE, .NET

1.      Categorized by dependency on container: container-dependent or container-less standalone web services

2.      Categorized by communication model: RPC and HTTP based web applications and XML messaging based standalone applications

·  Java WSDP 1.4 provides support for multiple Web containers. You can choose to integrate the Java WSDP 1.4 technology components with any of the following:

  • Sun Java System Application Server Platform Edition 8
  • Sun Java System Web Server 6.1
  • Tomcat 5.0 for Java WSDP
  • No Web container initially, then integrate with one of the previously mentioned Web containers or, with script modifications, with your own Web container at a later time

Java WSDP 1.4 adds support for the following profiles, based on draft versions dated April 19, 2004:

  • WS-I Basic Profile 1.1
  • WS-I Attachment Profile 1.0
  • WS-I Simple SOAP Binding Profile 1.0

Java API for XML-based RPC (JAX-RPC) v1.1.2 enables Java developers to develop SOAP-based portable Web services. JAX-RPC technology has support for the Web Services Interoperability Organization (WS-I) Basic Profile 1.1 with Attachments Profile 1.0. WS-I is an organization that aims at developing guidelines and tools to help developers in building interoperable Web services. The Basic Profile enables interoperability for your Web services, and the Attachments Profile compliments the Basic Profile 1.1 by adding support for conveying interoperable SOAP messages with attachments with SOAP messages.


J2EE with Web Services, category one;page=



J2EE Web services: A marriage of convenience

As specified in the following snippet taken from the J2EE specification, the J2EE platform contains details on the implementation, assembly, deployment and consumption of Web services: “J2EE provides full support for both clients of Web Services as well as Web Service endpoints. Several Java technologies work together to provide support for Web Services. The Java API for XML-based RPC (JAX-RPC) provides support for Web Service calls using the SOAP/HTTP protocol. JAX-RPC defines the mapping between Java classes and XML as used in SOAP RPC calls. The SOAP with Attachments API for Java (SAAJ) provides support for manipulating low-level SOAP messages. The Web Services for J2EE specification fully defines the deployment of Web Service clients and Web Service endpoints in J2EE, as well as the implementation of Web Service endpoints using enterprise beans. The Java API for XML Registries (JAXR) provides client access to XML registry servers.”

The life cycle of J2EE components and Web services is not dissimilar; they almost mimic one another as both have sprung from similar distributed computing ideologies. From modeling a Web service to its creation, binding, deployment, publishing and consumption, a Web service presents no new tenets for understanding, and its inclusion in the J2EE component stack is a logical addition to enable loosely coupled interaction between applications. The combination of J2EE and Web services seems to be a perfect match:



ASP.NET with Web Services, category one



XML Web services provide a way for applications to exchange data and processing capability. Typically, an XML Web service is a dynamic-link library (DLL) that resides on a Web server and whose methods can be called over the Internet. In this scenario, a client application communicates with an XML Web service by sending and receiving SOAP messages over Hypertext Transfer Protocol (HTTP).

In this article, we will demonstrate how to create, deploy, and access an XML Web service using Microsoft® Visual Studio® .NET. First, we'll set up Internet Information Server (IIS) on the Web server hosting the XML Web service.

Note   IIS 4.0 is compatible with Microsoft Windows NT® 4.0 Server. IIS 5.0 is compatible with and installed by default with Windows® 2000 Server.

Then, using Visual Studio .NET, we'll create an ASP.NET Web Service project. Next, we'll add code to the project to implement the XML Web service. Our sample XML Web service will accept the two-digit name of a U.S. state and return information about the state to include the state's full name, its capital, the date the state was admitted to the union, and its order of admittance. We'll then test the XML Web service in Visual Studio .NET. And finally, we'll create a client application using a Microsoft Access 2002 form to access the XML Web service and display the results.



WSE for Web Services, category two


The State of XML Messaging Today

Today one might expect to see many Web services, built over a variety of communication protocols and employing many different message exchange patterns. In reality, however, the vast majority of Web services are implemented as a collection of Remote Procedure Calls (RPC) over HTTP. This is primarily because that is the model promoted by most of today's Web service frameworks and toolkits. Such frameworks map the synchronous exchange of SOAP messages, carried in HTTP request and response messages onto the remote invocation of a method, on a class. HTTP was chosen because both client-side and server-side HTTP plumbing are available on every platform. The RPC model was adopted because of its familiarity and relative ease of use—it doesn't scare off developers. The RPC model is limiting, though. There are many other message-exchange possibilities if you are not tied to the predominantly synchronous, request-response model of RPC over HTTP. Also, the RPC approach eschews an XML-oriented view of data in favor of an object-oriented view, and this tends to lead to very tightly-coupled systems. There are real opportunities for building loosely-coupled systems that can evolve over time, if you are prepared to discard RPC and adopt a more XML-oriented view of the world.

It is generally possible to build a Web service that deviates from what the Web service runtime and tools want you to do. Even though the Microsoft ASP.NET .ASMX framework is geared towards implementing RPC-oriented Web services, it would be possible to write a more XML-oriented service by having the WebMethods accept an XmlNode as a parameter. HTTP cannot easily be replaced as the underlying protocol, however, as ASP.NET is centred on HTTP.


Sunday, March 12, 2006
xecers DOM parser validation
SchemaStr = TargetNamespace + " " + schemaFileLocation

SymString currentPath="C:\\pop\\mySoam\\servers\\sd\\adminManager\\u_test_xml\\";
SymString filename=currentPath+"sampleApp.xml";
SymString targetNamespace="";
SymString schemaFile=currentPath+"ApplicationProfile.xsd";
SymString schemaStr = targetNamespace + " " + schemaFile;
SymString buf;

hr = SymXmlUtil::copyXmlFile2Buffer(filename,buf,schemaStr);
ISymErrorInfo *error=symGetErrorInfo();

Friday, March 10, 2006
J2EE-Compatible Web Service creation and deployment
These are the basic steps for creating the web service and client: ()

1. Code the SEI (service endpoint interface) and implementation class and
interface configu
ration file(config-interface.xml, see step 3).

* It extends the java.rmi.Remote interface.
* It must not have constant declarations, such as public final static.
* The methods must throw the java.rmi.RemoteException or one of its subclasses. (The methods may also throw service-specific exceptions.)
* Method parameters and return types must be supported JAX-RPC types (see Types Supported by JAX-RPC).

2. Compile the SEI and implementation class.

3. Use wscompile to generate the files required to deploy the service.
config-interface.xml will specify
* service name
*WSDL target and type namespace
*SEI name,
*package Name where wscompile puts all the service classes into.

4. Use deploytool to package the files into a WAR file. (Assembling and Deploying Web Modules)
a. deployment descriptor ( Java Servlet Specification, v2.3, Chapter 13, Deployment Descriptors)
standard J2EE web.xml deployment descriptor for defining a Web Application
· ServletContext Init Parameters
· Session Configuration
· Servlet / JSP Definitions
· Servlet / JSP Mappings
· Application Lifecyle Listener classes
· Filter Definitions and Filter Mappings
· Mime Type Mappings
· Welcome File list
· Error Pages
· Security
* container specific deployment descriptor: sun-web.xml or weblogic.xml
b. webservice configuration xml (
for example, jaxrpc-ri.xml
· General Settings - This section specifies framework object classes and parameters such as the request processor, server ID, user manager class, etc.
· Web Services - Specifies Web services to be loaded and their properties.
· Interceptors - Specifies interceptors to be loaded.
· Service-Interceptor Mapping - Mapping specifying the chain of interceptors invoked for a Web service invocation.

5. Deploy the WAR file. The tie classes (which are used to communicate with clients) are generated by the Application Server during deployment.

6. Code the client class and WSDL configuration file.

7. Use wscompile to generate and compile the stub files.

8. Compile the client class.

9. Run the client.

Socket, reuse the same port
Use case:
After server is crashed, and is started over again, it will try to listen on the pre-configured port.
During a period of time(2 minutes or so), the port status is CLOSE_WAIT. If the port is not reusable, then the second binding will fail.
Use SO_REUSEADDR option for the socket,
For example, in gSoap,

soap.bind_flags = SO_REUSEADDR;
master = soap_bind(&soap, NULL, port, 100);

in socket programming, we can use setsockopt, please refer to

Tuesday, March 07, 2006
TCP/IP keep alive parameter
[In the testing in IBM blade, Linux2.4 kernel, somehow, we can not get expected behavior]

Use case.
A and B have set up TCP/IP connection. At some time, B is powered off, or the networking cable is unplugged.

In this case, TCP/IP protocol will depend on the Ti, Nm, Td to do liveness checking

In Linux, you can read this value by

[puliu@ib04b14 ~]$ /sbin/sysctl -a | grep tcp_keepalive_time
net.ipv4.tcp_keepalive_time = 7200

and set this value by

[puliu@ib04b14 ~]$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_time = 10

[puliu@ib04b14 ~]$ sudo /sbin/sysctl -a -e | grep 'tcp_keepalive_time'
net.ipv4.tcp_keepalive_time = 10

Here is the detailed information from

I quote them as follows:

MobiLink & TCP/IP Keep-Alive

The MobiLink TCP/IP-based communications streams have a "keep_alive" option. This article discusses how to set this option effectively.

What Is the keep_alive Option?

The keep_alive option enables or disables liveness checking over a TCP/IP connection. Liveness checking is the process of checking whether or not the other end of a network connection is still connected ("alive"). It only applies to the end of a connection that is waiting to receive data, since the sending end finds out about a lost connection as soon as it tries to send data.
Why Liveness Checking Is Important

Liveness checking prevents the listening side of a connection from waiting indefinitely when a connection is lost. This lets servers like MobiLink discard client connections that have disappeared. Without liveness checking, a server can dedicate too many resources to lost connections it thinks are still alive. On the client side, liveness checking helps detect failed connections so that the user can be notified, and perhaps try again later or try a different server.

Without liveness checking, a dropped connection will either hang the client or the MobiLink worker thread to which the client was connected. If MobiLink was at a point in the synchronization where it was waiting for data from the client, then that worker thread will continue to wait and never be available for other synchronizations. If the client was waiting for data from MobiLink, then the client would continue to wait and never complete the synchronization. Since MobiLink synchronizations have communications in both directions, you need to enable liveness checking on both the MobiLink server and the client to prevent either side from hanging on lost communications.
How To Set the keep_alive Option In MobiLink Servers and Clients

The TCP/IP-based streams that are used during MobiLink synchronization now accept a new parameter, both on the client and server side:


To enable liveness checking in 7.0.x MobiLink, for example, your command line should contain the following:

dbmlsrv7 -x tcpip{keep_alive=1} ....

0 turns off TCP/IP liveness checking, and 1 enables it. The default is 1 (liveness detection enabled). If the network layer doesn't support TCP/IP liveness checking, this parameter is ignored. The default was initially 0, but our customers kept running into problems that were solved by having the option enabled, so the default was changed to 1. When in doubt, set the keep_alive option explicitly.

Consult your UltraLite and ASA client for MobiLink documentation for details on setting TCP/IP stream options in MobiLink clients.

The following SQL Anywhere Studio releases (and EBFs), and all later releases, have the keep_alive option available:

Setting the keep_alive option to 1 isn't usually enough, however. The operating system's settings for TCP/IP liveness checking may need to be altered to suit your application, but first you need to understand some of the liveness-checking details.
How TCP/IP Liveness Checking Works

The OS network layer's implementation of liveness checking are slightly different for each OS, but the following basic algorithm applies:

IF( waiting for data on TCP/IP connection for at least time Ti ) {

// Begin liveness checking:
Repeat = Nm
WHILE( there is no response from the other side AND Repeat > 0 ) {

Send a keep-alive message
Wait for reply up to time Td
Repeat <- Repeat - 1

IF( there was no response ) {

Declare the connection dead

} ELSE {

Reset the count of time waiting for data




The bolded values (Ti, Nm, and Td) are example names, created for the purposes of this discussion, that represent OS/network settings.

* Ti is the idle time threshold. Any connection idle for at least this time is a candidate for liveness checking.
* Nm is the maximum number (unsigned integer) of keep-alive messages that can be sent before a connection is declared dead.
* Td is the minimum delay that is applied between keep-alive messages.
* Once a connection is declared dead, any current or subsequent attempt to communicate on that connection will fail immediately with an error.
* Some TCP/IP implementations may use a progression of geometric delays by applying a formula to Td, but that isn't discussed here.
* The keep-alive message is a simple, low-level message. If the connection is still present, the other end will use fundamental TCP/IP functionality to reply, without affecting the sending application. The cost of a liveness check is negligible; because it is implemented via an exchange of TCP/IP ACKs there is minimal network or processor utilization.

The key to setting up liveness checking is to choose and set the idle time threshold (Ti) that must elapse before the checks actually take place on an idle connection. Usually you should not need to change the other parameters.
What Idle Threshold Should You Use?

Your choice for Ti really depends on your deployment, and your network characteristics in particular. You want an interval that is long enough to prevent falsely declaring a connection to be dead, but shorter than the time you are willing to wait before detecting a dropped connection. Note that the total time before a dead connection is declared is Nm * Td + Ti, not just Ti. To avoid false detections, you need to make sure that the idle and delay time settings are significantly longer than the round-trip time for the network connection. You can use a "ping" utility (included with Windows and Unix) to determine round-trip times for network connections. If you are using a network with low bandwidth or high latency, such as a dialup, wireless WAN or satellite network, than you would probably need larger idle time than with a low-latency, high-bandwidth network.

Also, if your deployment relies on repeated, scheduled synchronizations, you probably want to set the interval to a value that detects dropped connections well before the next synchronization is attempted.

Now that you know what to set the interval to, let's look at how you can set it on various operating systems.
How To Set the Idle Threshold on Windows

The Windows default settings are as follows:

Ti = 2 hours
Nm = 5
Td = 5 seconds

Windows relies on system-wide registry settings to set a single check interval for an entire machine. Even worse, the default is to wait two (2) hours before checking for a dropped connection! This is usually inadequate for responsive liveness checking.

NOTE: This setting is shared by all applications that request TCP/IP keep-alive. Any such applications want to detect lost connections, so picking parameters appropriate for your network will likely benefit those applications as well as MobiLink. However be aware that the Nm parameter is also used for data retransmissions irrespective of TCP/IP keep-alive, so it should only be changed after careful consideration. Future releases of ASA Studio may include the ability to let you control the keep-alive behaviour without affecting other applications.
Windows 95/98/ME

Some of the registry entries below may not already exist. You may need to create some of them. Once modified, you will have to reboot for the new settings to take effect.

WARNING: Modifying your registry is DANGEROUS. Modify your registry at your own risk.

The registry entry for Ti is a DWORD value with millisecond units:

The registry entry for Nm is a String value:

The registry entry for Td is a DWORD value with millisecond units:

Windows NT/2000/XP

Some of the registry entries below may not already exist. You may need to create some of them. Once modified, you will have to reboot for the new settings to take effect.

WARNING: Modifying your registry is DANGEROUS. Modify your registry at your own risk.

The registry entry for Ti is a DWORD value with millisecond units:

The registry entry for Nm is a String value:

The registry entry for Td is a DWORD value with millisecond units:

Windows CE

Some of the registry entries below may not already exist. You may need to create some of them. Once modified, you will have to soft reset for the new settings to take effect.

WARNING: Modifying your registry is DANGEROUS. Modify your registry at your own risk.

The registry entry for Ti is a DWORD value with millisecond units:

The registry entry for Nm is a String value:

The registry entry for Td is a DWORD value with millisecond units:

How to Set the Liveness-Checking Interval on Sun Solaris

Use the ndd utility to set the tcp_keepalive_interval (Ti), in milliseconds. The following sets the value to the default of 2 hours:

ndd -set /dev/tcp tcp_keepalive_interval 7200000

You can inspect the current value as follows:

ndd -get /dev/tcp tcp_keepalive_interval

You must have the proper permissions (root will do) to be able to set this value. Consult your system administrator for details.
How to Set the Liveness-Checking Interval on Linux

You must write a program, or find a utiltity, that makes use of the sysctl function to set system parameters. The details are too tedious to go into here, but the relevant parameters are tcp_keepalive_time (Ti), in seconds, and tcp_keepalive_probes (Nm).

- The Microsoft Developers Network (MSDN), October 2000.

- Sybase Technical News, Volume 7, Number 8, August 1998 (from ISUG):

Powered by Blogger