OBEX Server Architecture (Windows Embedded CE 6.0)
1/6/2010
The following diagram illustrates how the Obexsrvr.dll and extensions supplied by Windows Embedded CE are implemented.
.gif "Ee494459.91161914-d8b5-4af9-aaa1-d0383e8ecb04(en-US,WinEmbedded.60).gif")
The OBEX transport layer receives a packet from the client. The packet is checked for correctness, bounds overflow, and so on. If the format is incorrect, it is rejected and the appropriate response is returned to the requester.
If the packet is an OBEX CONNECT packet, a new connection is allocated and a connection identifier is generated.
If the packet is a non-CONNECT packet and a connection is not established, a default temporary connection is allocated and a connection identifier is generated.
If the packet is a continuation of a GET or Put method, the connection identifier from the initiating command is used.
The connection identifier is a service alias. The TARGET field in a CONNECT packet defines what service to use, based on the connection identifier. If a default connection was generated, the TARGET field in an individual package defines what service to use. For Windows Embedded CE, if the connection identifier or TARGET is not present, the connection is assumed to be for DEFAULT INBOX.
The appropriate service extension, defined by the connection target, is loaded.
Note
Service extensions may be loaded at startup by using protocol and registry entries.
The packet is passed to a service extension's entry point. The service processes the request. Before the call returns, a response packet is sent to the OBEX server. If the server does not receive this packet, an error is assumed and a generic SERVICE UNAVAILABLE error is returned.
The server reformats the package to the OBEX network format then forwards the packet to the requesting transport layer.
The transport layer sends the packet back to the client.