S-Connect

S-Connect

S-Connect is a primitive that is used to initiate session establishment and to notify of its success. It
also provides one-way capability negotiation with the client being the initiator and the server being
the responder. The primitive contains, among other things, the server and client address that identifies
the peer and the originator respectively of the current session.



1. A S-Connect request from the client, i.e. the mobile device.
2. The server i.e. WAP gateway examines the request and returns a result, hopefully an
acknowledgement of a successful establishment.
3. The client receives the acknowledgement and can begin to send Method Invoke requests (i.e.
ask for web pages or other information), discussed in 5.1.3. The client can begin to request
information before it receives an acknowledgement for the session establishment but if there
is a failure in the establishment some cleaning in the cache has to be done.
This is all it is to it, but the real fun stuff starts when we also have a connection from the gateway to a
web server, but first we take a look at the timeline for the disconnection.


S-Disconnect
There is another primitive called S-Disconnect that is used when either of the sides wants to close the
session. Before the disconnect indication, the session service provider must abort all incomplete
method and push transactions. After the indication further primitives associated with the session must
not occur.
A disconnect indication generated by the service provider can occur at any time during the session.
The service user must be prepared for the session being disconnected at any time. If it wishes to
continue communication, it has to establish the session again and retry the method invocations that
may have been aborted. The S-Disconnect induction is received either when a connection is refused
or when a connection is closed by the gateway.