Symbian OS Communications (779884), страница 69
Текст из файла (страница 69)
This also provides a means by which multipledirected OBEX sessions can be multiplexed over a single underlyingtransport connection (see Figure 10.10).Symbian OS implements a weaker form of directed connections,where the OBEX server can determine the requirements of the OBEXclient (based on a Target header sent with a Connect request packet).The OBEX server may then reject the connection if it cannot, or will not,service the OBEX client’s needs.
No OBEX level routing or multiplexing issupported (although arguably a single OBEX client can connect to a serverthat offers multiple services – it simply can’t be connected to more thanOBEX Server(Who == "Service X")OBEX Server(Who == "Service Y")OBEX Session, Connection ID = 1OBEX Session estabished byremote client connecting withTarget Header == "ServiceX", server allocatingConnection ID 1Transport linkOBEX MultiplexerFigure 10.10 OBEX directed connectionsOBEX Server(Who == "Service Z")336OBEXone of these services simultaneously). The lack of full-directed connectionsupport does not generally cause problems because the transports overwhich OBEX runs (Bluetooth and IrDA) provide their own methods ofservice discovery, routing and multiplexing (see Figure 10.11).Directed connections are tied up with the use of the Target header,the Who header and the Connection ID header, as described in ‘Target,Who and Connection ID headers’ in section 10.1.2.OBEX client and directed connectionsThe role of OBEX clients in Symbian OS in forming directed connections isquite small.
They can specify a target header to be sent during connectionby creating an object containing a Target header and passing this objectinto Connect() or ConnectL() used to initiate the connection. Oncethe transport link to the OBEX server has been established, the Targetheader is transmitted to the OBEX server as part of the Connect requestpacket.If the connection attempt is successful, the OBEX client will receivea Connect response packet containing a Who header and a ConnectionID header.
The Who header indicates the identity of the service providedby the OBEX server (which will normally match the Target header), andthe Connection ID uniquely identifies the session established betweenFigure 10.11 OBEX using transport multiplexingTransport link 3OBEX Server(Bluetooth SDP recordindicates "BIP")OBEX SessionTransport link 2OBEX Server(Bluetooth SDP recordindicates "OPP")OBEX SessionTransport link 1OBEX SessionOBEX Server(Bluetooth SDP recordindicates "FTP")OBEX IN SYMBIAN OS337the OBEX client and OBEX server.
Symbian OS applications do not needto concern themselves with these details, however, as the Symbian OSOBEX implementation takes care of these headers automatically. If anOBEX client application does wish to know the Who identity of theremote server, it can use CObex::RemoteInfo() to retrieve detailsof the remote server (including the value of the Who header) collectedduring the connection process.
The Connection ID is unlikely to be of useto OBEX applications, but may be extracted by the OBEX server from theheader set of any object transferred from OBEX client to an OBEX serverover a directed connection.OBEX server and directed connectionsIn Symbian OS the options open to an OBEX server application relating todirected connections are a little wider.
The OBEX server application maychoose one of three methods to apply to processing the Target headerduring connections, each one being useful in different circumstances.The three methods are identified in an enumeration CObexServer::TTargetChecking as shown in Table 10.6.(Note: ‘Correct’ in this context means that the Target header matches theOBEX server’s ‘Who’ value.)The OBEX server application can choose the method required by calling CObexServer::SetTargetChecking() before calling CObexServer::Start().The behaviour of each method is described below, along with anexample of a situation in which that method might be considered mostappropriate.ENoChecking is the most promiscuous of the behaviours: whenusing this method, CObexServer will accept all connection requestsregardless of whether a Target header is included or not included inthe Connect request packet(s), and regardless of the value of the Targetheader.
An OBEX server application choosing to exhibit this behaviourTable 10.6 Symbian OS OBEX target header checking methodsMethodOBEX server behaviourENoChecking Always allow the connection, regardless of presence, absenceor value of Target headerEIfPresentAllow the connection if the Target header is absent, or presentand the correct value (this is the default behaviour for theSymbian OS OBEX server component)EAlwaysAllow the connection if the Target header is present and thecorrect value338OBEXmight be some kind of multi-purpose application that advertises multipleservices over the same transport link, but performs different servicesdepending upon the Target header provided by the OBEX client.EIfPresent is the default behaviour for the Symbian OS OBEXserver.
When using this method, the OBEX server component checks theTarget header only if it has been sent as part of a Connect request. Ifthe Target header is present and incorrect, the connection is rejected.This method relies on the service discovery, routing and multiplexingmechanisms of the underlying transport working correctly, and the OBEXdirected connection mechanism is simply used as a further level ofchecking. Unless multiple OBEX services are being advertised over asingle transport link, this behaviour is normally entirely adequate.EAlways is the most strict of the behaviours. In this case, connectionsare only accepted where the Target header is present and correct inthe Connect request.
This behaviour is best suited to specialized OBEXapplications whose specification insists on the use of Target headers.10.2.9 Platform Security Requirements of OBEXAs mentioned in section 10.2.3 above, the Symbian OS OBEX implementation runs in the same thread as the OBEX application code which hostsit. Symbian OS platform security is applied on process boundaries (andduring DLL loading) only, so OBEX itself does not place any platformsecurity requirements on applications that use it.However, OBEX makes use of transport technologies that do placeplatform security requirements on their clients – in this respect, OBEXand OBEX applications count as clients of these transport technologies.For Bluetooth and IrDA, this means the use of LocalServices capability.
More information on the platform security requirements of thesetechnologies can be found in their respective chapters.10.2.10 Changes in Symbian OS v9.2Symbian OS v9.2 includes a number of small but significant changesto the OBEX APIs. These changes do not break source or binarycompatibility with v9.1, so code written and binaries built against v9.1will continue to build and work. The most important of these changesare described below.Asynchronous server APIAs mentioned above, the synchronous nature of the interface defined byMObexServerNotify is occasionally inconvenient when asynchronousprocessing is required to decide how to respond to a request indication.OBEX IN SYMBIAN OS339For this reason, in Symbian OS v9.2, a new interface has beendefined to remove this restriction.
The new interface consists of aclass MObexServerNotifyAsync and a group of new functions forCObexServer.MObexServerNotifyAsync looks very similar indeed to MObexServerNotify, but on close inspection you may notice that some ofthe functions differ with regards to return parameters, coloured grey inTable 10.7.The functions for which the return value disappears may now be usedasynchronously. What this means in practical terms is that the applicationcode that implements the functions can return program control to theCObexServer (note the void return parameters) and do whateverprocessing they need to do asynchronously before finally giving theTable 10.7 Comparison of MObexServerNotify and MObexServerNotifyAsyncFunctionReturn valuein MObexServerNotifyReturn valuein MObexServerNotifyAsyncErrorIndicationvoidvoidTransportUpIndicationvoidvoidTransportDownIndicationvoidvoidObexConnectIndicationTIntvoidObexDisconnectIndicationvoidvoidPutRequestIndicationCObexBufObject*voidPutPacketIndicationTIntTintPutCompleteIndicationTIntvoidGetRequestIndicationCObexBufObject*voidGetPacketIndicationTIntTintGetCompleteIndicationTIntvoidSetPathIndicationTIntvoidAbortIndicationvoidvoidCancelIndicationCallbackNot present invoidMObexServerNotify340OBEXCObexServer the object or response value it needs to proceed with theOBEX exchange.The way in which the OBEX server application does this is byusing the appropriate function out of several new functions added toCObexServer in Symbian OS v9.2.To complete processing of a PutRequestIndication() or aGetRequestIndication() upcall, the OBEX server application mustcall one of the following three new functions on CobexServer:TInt RequestIndicationCallback(CObexBaseObject* aObject);TInt RequestIndicationCallbackWithError(TObexResponse aResponseCode);TInt RequestIndicationCallbackWithError(TInt aErrorCode);The first function is used when the OBEX server application wishes toproceed with the transfer.
One of the second and third functions is usedwhen the OBEX server application wishes to abandon the transfer withan error code. The second function allows the OBEX server applicationto directly specify an OBEX error code to be used in the response packet,while the third function takes a Symbian error code and maps it to anOBEX response code in the usual way.To complete processing of a PutCompleteIndication(), a GetCompleteIndication() or a SetPathIndication(), the OBEXserver application must call one of the following two new functions onCObexServer:TInt RequestCompleteIndicationCallback(TObexResponse aResponseCode);TInt RequestCompleteIndicationCallback(TInt aErrorCode);These two overloads of RequestCompleteIndicationCallback() correspond to the two overloads of RequestIndicationCallbackWithError() in the treatment of their arguments.Once these ‘callback’ functions have been called appropriately, processing of the request proceeds just as in Symbian OS v9.1.
Care should betaken to call the functions only when appropriate – that is after a requestindication upcall or a request complete indication upcall – becauseCObexServer will panic if these functions are abused.The other significant additional function in MObexServerNotifyAsync is CancelIndicationCallback(). This function is usedby CObexServer to inform an OBEX server application that a problemhas occurred and the callback is no longer necessary. When CancelIndicationCallback() is called, the OBEX server applicationmust heed this information and not call back, or a panic will result.Readers should note that the change of return parameter on ObexConnectIndication() from TInt to void is not due to an attemptto somehow make that indication asynchronous, but rather simply toSUMMARY341remove an unnecessary parameter from the function (the returned TIntspecified in the MObexServerNotify class is a historical anomaly, andhas no effect on processing of the Connect requests).Setting timeouts on Client commandsCObexClient has a new member function in Symbian OS v9.2 to enableOBEX client applications to protect against OBEX servers that becomeunresponsive during OBEX sessions.An OBEX client application that calls CObexClient::SetCommandTimeOut() prior to initiating an OBEX command will be protectedagainst unresponsive OBEX servers by a timer that starts when the OBEXrequest packet has been sent to the OBEX server.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
