Using Socket Connections
Go Up to Choosing a Connection Protocol
TCP/IP Sockets let you create lightweight clients. For example, if you are writing a Web-based client application, you cannot be sure that client systems support DCOM. Sockets provide a lowest common denominator that you know will be available for connecting to the application server. For more information about sockets, see Working with Sockets.
Instead of instantiating the remote data module directly from the client (as happens with DCOM), sockets use a separate application on the server (ScktSrvr.exe), which accepts client requests and instantiates the remote data module using COM. The connection component on the client and ScktSrvr.exe on the server are responsible for marshaling IAppServer calls.
Note: ScktSrvr.exe can run as an NT service application. Register it with the Service manager by starting it using the -install command line option. You can unregister it using the -uninstall command line option.
Before you can use a socket connection, the application server must register its availability to clients using a socket connection. By default, all new remote data modules automatically register themselves by adding a call to EnableSocketTransport in the UpdateRegistry method. You can remove this call to prevent socket connections to your application server.
Note: Because older servers did not add this registration, you can disable the check for whether an application server is registered by unchecking the Connections > Registered Objects Only menu item on ScktSrvr.exe.
When using sockets, there is no protection on the server against client systems failing before they release a reference to interfaces on the application server. While this results in less message traffic than when using DCOM (which sends periodic keep-alive messages), this can result in an application server that cannot release its resources because it is unaware that the client has gone away.