Symbian OS Communications (779884), страница 66
Текст из файла (страница 66)
Please note that requesting Bluetoothauthentication for a link between two devices that have not previouslyauthenticated each other will result in a process called ‘pairing’.Device discoverability and ‘connectability’ – Discoverability and connectability are characteristics that describe the fundamental behaviour ofa device when some other device is attempting to find it or connect toit using Bluetooth.
These values must be set correctly, or the rest of thesetting up above will be of no use!320OBEXWhen a device is offering an OBEX service, generally the device willneed to be both discoverable and connectable. However, there may besome circumstances where the device only need be connectable, i.e.,when the OBEX client device and the OBEX server device have a fixedrelationship. For example, if the phone contains a database that needsto be regularly synchronized to the same PC; the phone may remainconnectable but not discoverable, and the PC can store the phone’sBluetooth device address. The PC will then be able to connect to phonewithout first discovering it.All this being said, control of discoverability and connectability isa device-wide consideration – OBEX server applications should not betrying to control discoverability or connectability of the local device.However, they may want to consider providing feedback to the user ifthere is some major problem that will affect their function, for example,Bluetooth is switched off!Start and StopThe Start() and Stop() functions of CObexServer provide an ‘on/offswitch’ for OBEX services.Calling Start() achieves two things.
Firstly, it allows the OBEX serverapplication to provide CObexServer with a reference to an instance ofan MObexServerNotify-derived class. As mentioned above, the classimplementing the MObexServerNotify interface responds to incomingevents from remote OBEX clients, and so defines the behaviour of theOBEX service.The class implementing the MObexServerNotify interface mustbe ready to start handling events because, secondly, Start() enablesthe transport to accept incoming connections.
Once incoming connections commence, events will start to happen, triggering calls onto theMObexServerNotify-derived object.Stop() can be called at any time once the CObexServer has beenstarted. Stop() will abandon any ongoing OBEX session activity bybringing down any transport link that has been established. No furtherconnections to the OBEX service will be allowed until Start() is calledagain.Note that Stop() is called as part of CObexServer’s destructor, soit is valid to simply delete an instance of CObexServer without callingStop() first when rapid shutdown is required.MObexServerNotifyMObexServerNotify defines a set of functions corresponding to eventssuch as changes in transport status, and incoming OBEX request packets.The class that implements MObexServerNotify is required to respondOBEX IN SYMBIAN OS321to these incoming OBEX events, usually taking service-specific actionupon receiving them.
For example, on being informed of an incoming Putrequest, the class must provide a prepared object in which to store theincoming data; what happens to that object once the transfer is completeis service-specific.MObexServerNotify defines a synchronous interface; that is, theclass implementing the interface must respond to an event by the time itreturns program control to the CObexServer class.This is an occasionally inconvenient limitation that is addressed in theSymbian OS v9.2 release (see section 10.2.10).Transport-related events and OBEX sessionCObexServer will keep the MObexServerNotify-derived objectpassed into CObexServer::Start() informed of changes in the transport status and OBEX session status.Connection CObexServer will call TransportUpIndication()when the Bluetooth or IrDA transport link is established – this is before anyOBEX request/response packets have passed over the link to establish theOBEX session.
An OBEX server application can use this as an opportunityto initialize itself prior to receiving a Connect request.Like CObexClient, CObexServer handles connection establishment automatically on behalf of the application, including any requestedauthentication and directed session activities. Once the OBEX sessionhas been successfully established, CObexServer will call ObexConnectIndication() to indicate this to the OBEX server application. ObexConnectIndication() passes a TObexConnectInfo asa parameter.TObexConnectInfo contains a digest of useful information aboutthe connected OBEX client application, including the Target headerthat the client application used during connection process. This can beused to discover the intent of the OBEX client application, and so modifybehaviour of the OBEX server application accordingly.
See section 10.2.8on directed connections for more information on the subject of Targetheaders.Once ObexConnectIndication() has been called, the OBEXserver application should be prepared to respond to OBEX requests.Please note that the return value TInt of ObexConnectIndication()is a historical anomaly, and whatever value is returned here has no effecton the operation of CObexServer. In this sense, TransportUpIndication() is purely an indication; it reports something that has alreadyhappened, and does not offer an opportunity to reject the connection.322OBEXUnsuccessful connection attempts (e.g., ones where authenticationprocedures have failed) are not reported to the OBEX server application.
In these circumstances, the OBEX server application will ‘see’ aTransportUpIndication(), followed some short time later by aTransportDownIndication() as the client disconnects the transportlink after its failure to establish an OBEX session.Disconnection An OBEX client may disconnect a session with an OBEXserver in one of two ways: either by sending an OBEX Disconnectcommand to bring down the OBEX session followed by a transportdisconnection; or by simply disconnecting the transport. Both methodsare valid according to the OBEX specification, although the first isconsidered more ‘polite’, and may in some circumstances be useful (itis not impossible that a Disconnect request may contain some header toindicate the reason for the disconnection for instance).As a result, the OBEX server application may see an ObexDisconnectIndication() called on the MObexServerNotify-derivedobject, followed by a TransportDownIndication().
Alternatively,the OBEX server application may see only a TransportDownIndication(). The OBEX server application may find it convenient to useTransportDownIndication() as an opportunity to release resourcesrequired only during an active OBEX session.Handling PutsPutRequestIndication Upon receiving the first Put request packetof a Put command, CObexServer will call PutRequestIndication() on the MObexServerNotify-derived object passed intoCObexServer::Start(). This allows the OBEX server applicationto provide a CObexBufObject 13 into which the headers making up theobject are to be stored.
The address of the CObexBufObject is usedas the return value for PutRequestIndication(). The OBEX serverapplication retains ownership of the object.If NULL is used as the return value of PutRequestIndication(),the Put response packet is sent to the client with a ‘Forbidden’ response.Symbian OS v9.2 will make it possible to return a wider variety ofresponse codes in this situation.CObexBufObject* CObexFtpServer::PutRequestIndication()13Note specifically a CObexBufObject, rather than any CObexBaseObject derivedclass as might be expected.
This is another historical anomaly that is addressed in SymbianOS v9.2.OBEX IN SYMBIAN OS323{iTest.Printf(KObexPutIndication);//We will try and receive an object into the current directoryTInt err=SetupReceiveObject();if(err){// We couldn’t set up the receiving objectiTest.Printf(KObexPutRequestIndError, err);return NULL;}return iReceiveObject;}TInt CObexFtpServer::SetupReceiveObject(){// Non-leaving equivalent to SetupReceiveObjectL()TRAPD(err,SetupReceiveObjectL());return err;}void CObexFtpServer::SetupReceiveObjectL(){delete iReceiveObject;iReceiveObject=NULL;// iTempFileName is a TFileName// iFileSpec is a TParse containing the current path//iTempFileName.Copy(iFileSpec.DriveAndPath());iTempFileName.Append(KTempFileName);// iReceiveBuf is a preallocated CBufFlat//TObexFilenameBackedBuffer bufDetails(*iReceiveBuf, iTempFileName,CObexBufObject::ESingleBuffering);iReceiveObject = CObexBufObject::NewL(NULL);iReceiveObject->SetDataBufL(bufDetails);}Example 10.17 Implementation ofMObexServerNotify::PutRequestIndication()PutPacketIndication Once the MObexServerNotify-derivedobject has returned the CObexBufObject pointer, the CObexServercalls PutPacketIndication() onto the same MObexServerNotify-derived object.This PutPacketIndication() call is made for the first and theneach subsequent incoming Put request packet, and provides a meansby which transfer progress may be tracked and perhaps indicated ona UI.
It also offers an opportunity for the OBEX server applicationto respond to a Put request packet with an error response code, and324OBEXso brings the Put command to a premature halt. The return value ofPutPacketIndication() is a Symbian style error code, and shouldalways be KErrNone unless the server application wishes to stop the Putcommand.
The same rules as described in ‘OBEX command completionand error codes’ apply to mapping between Symbian style error numbersand their corresponding OBEX response codes.Because PutPacketIndication() is called for each request packetin an exchange, it is important that the processing that takes place inthe implementation of the function is as lightweight and fast as possible;delays in processing a PutPacketIndication() call will delay theCObexServer’s response.
Particularly when using small packet sizes,these delays can mount up to considerably impair the performance of thetransfer.PutCompleteIndicationOnce the final request packet of thePut command has been received, the CObexServer calls PutCompleteIndication() onto the same MObexServerNotify-derivedobject. PutCompleteIndication() indicates that the transfer is over,and the object provided in response to PutRequestIndication() isready to be inspected, processed or stored as appropriate.PutCompleteIndication() allows the OBEX server applicationto respond to the final Put request packet with an error response codein the same way as PutPacketIndication() does.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
