Symbian OS Communications (779884), страница 34
Текст из файла (страница 34)
A single slot discovery will return most quickly, but may failto return any devices when more than one device responds to the query.Valid values are 1, 6, 8 or 16. The recommended default value is 6.150INFRAREDKUserBaudOptKHostMaxDataSizeOptKRemoteMaxDataSizeOptKHostMaxTATimeOptKIrlapDisableResetOptThese values should not generally be changed, but can be read todetermine the status of an established link. Under certain situations itmay be necessary to change the host values, but as this is strongly discouraged, this use is not discussed here. Generally, the highest baudrate supported by both stations is used, together with the highest maximum turnaround time. This combination provides maximum throughput,although at the cost of a slightly increased maximum latency.
KUserBaudOpt, KHostMaxDataSizeOpt and KMaxTATimeOpt all need theNetworkControl capability.KLocalBusyDetectedOptKLocalBusyClearedOptThese flags allow the programmer to set or clear a ‘local busy state’.This state acts as flow control on the lowest level of the link – in abusy state, any packets sent by the remote station are rejected but thelink is maintained until the busy state is cleared. It is recommendednot to use this option, especially as KLocalBusyDetected needs theNetworkControl capability.KDiscoveryResponseDisableOptDisable responses to incoming discovery attempts for three seconds. Thisallows the local station to establish itself as the primary, without otherstations connecting in. This should not generally be required, but canincrease connection reliability when interoperating with certain otherIrDA implementations. As such it is recommended that it be set if theapplication has the NetworkControl capability.
Any failure to set this,however, should not be regarded as critical.KFirstHintByteOptKSecondHintByteOptSet or get the first and second hint bytes. These bytes provide coarsegrained service discovery, and are described in section 5.3.6. However,setting them requires the NetworkControl capability.KTinyTPLocalSegSizeOptKTinyTPRemoteSegSizeOpIRDA IN SYMBIAN OS151Find or set the local and remote TinyTP segment size. This value is usedwhen TinyTP Segmentation and Reassembly is in use. Under normalcircumstances, due to known problems in other implementations, theIrDA SIG recommends that SAR not be used.
When setting the local size,values greater than 2048 bytes may not be used.KTinyTPDisabledSegmentationDespite advertising a zero length reassembly buffer, some TinyTP implementations may still attempt to send SAR data. Setting this flag will tellthe socket to treat individual TinyTP PDUs as individual SDUs, evenwhen the header data claims that multiple packets should be concatenated together.
Apart for providing more SDU boundaries than the senderintended, the data are unaffected.5.3.12 IoctlsThese ioctls may be passed to RSocket::Ioctl(), in order to promptthe stack to perform a variety of actions. Unless otherwise indicated, allof these ioctls require the LocalServices capability.Ioctls differ from socket options in that they are asynchronous – as aresult many of these are callback notifications.KDiscoveryIndicationIoctlCompletes when a remote station discovers the local machine. Theprovided descriptor is filled with the TNameRecord related to the devicewhich has discovered the local machine.KExclusiveModeIoctlKMultiplexModeIoctlRequests the stack treat the current socket as ‘exclusive’. This preventsall other sockets from sending data, so preventing deadlocks betweenmultiple IrMUX level sockets.
This ioctl will fail unless the socket specifiedis the only socket currently open on the link. Trying to set exclusive modealso requires the NetworkControl capability.KIrmuxStatusRequestIoctlKIrlapStatusRequestIoctlKIrlapStatusIndicationIoctlKIrmuxStatusIndicationIoctlThese ioctls are in fact largely identical, and report the major status ofthe IrLAP link. The only difference is that the Request ioctls report thecurrent status, while the Indication ioctls wait for a state change.KIdleRequestIoctl152INFRAREDKIdleClearRequestIoctlThese ioctls may be used to allow a link to be placed into exclusive modeeven when multiple open sockets exist.
Only if all other open socketshave been marked as idle will the exclusive mode transition is allowed.KDisconnectIndicationIoctlCompletes to indicate that the socket has been closed. This will be followed by any outstanding read or write attempts on the socket completingwith an error. The supplied descriptor is filled with an integer representingthe reason for the link’s disconnection (see Table 5.4).Table 5.4 Reason for link disconnectionValueReason0x01User request0x02Unexpected IrLAP disconnect0x03Failed to establish IrLAP connection0x04IrLAP reset0x05Link management initiated disconnect0x06Data delivered on disconnected LSAP connection0x07Non-responsive LM-MUX client0x08No available LM-MUX client0x09Connection half open0x0AIllegal source address0xFFUnspecified disconnect reasonKIrlapResetRequestIoctlRequests that the underlying IrLAP link be reset.
This will discard anydata currently stored in the protocol’s buffers, on both sides of the link.An unknown amount of data will therefore be lost. This requires theNetworkControl capability.KIrlapResetIndicationIoctlCompletes to indicate that the underlying IrLAP link has been reset.SUMMARY153KIrlapDisconnectRequestIoctlRequests that the underlying IrLAP link be disconnected.
This requiresthe NetworkControl capability.5.3.13 Monitoring Link StatusTo monitor status changes on the link, a Publish and Subscribe keyhas been defined. This key progresses through seven states, showingthe stack being loaded or unloaded, as well as discovering a remotedevice, losing the discovered device, connected, disconnected, and thelink being interrupted.A typical sequence might look like:TIrdaStatusCodes::EIrLoadedTIrdaStatusCodes::EIrDiscoveredPeerTIrdaStatusCodes::EIrLostPeerTIrdaStatusCodes::EIrConnectedTIrdaStatusCodes::EIrBlockedTIrdaStatusCodes::EIrDisconnectedTIrdaStatusCodes::EIrUnloadedThe Publish and Subscribe key is in category KIrdaPropertyCategory (defined as being KUidSystemCategoryValue), and the keyitself is KIrdaStatus.Watching for EIrDiscoveredPeer is another method of waiting forremote discoveries, therefore avoiding the need to use the ioctl valueKDiscoveryIndicationIoctl.
It is important to note, however, thatPublish and Subscribe is not intended as a reliable service – in the sensethat if values are published very rapidly then some listeners may notreceive all published values. As such, if it is important that you are notifiedon remote discoveries then using the ioctl may be the preferable option.5.4 SummaryIn this chapter we have learnt:• about the general concepts in IrDA• how to discover other devices using IrDA• how to query the IAS (service) database on remote devices• how to add entries to our local IAS database to allow other devices toconnect to services that we offer• how to connect outgoing and receive incoming socket connections• about the socket options that IrDA offers for additional control of thestack.6IP and Related TechnologiesIP is the most common protocol for data communications today, andis likely to become even more popular in the near future as voiceservices migrate to use IP. Most mobile devices have IP connectivity foraccessing the Internet, connecting to email services, and for using otherservices that network operators make available over GPRS.
Additionally,increasing numbers of mobile devices now enable IP over more thanjust the GPRS network; both WLAN and the Bluetooth PAN profileenable connectivity to a wider range of services, including ad-hoc localnetworks (such as multi-player games) and convergent networks (such asUMA and IMS) where the same services can be accessed over differenttechnologies, in addition to being used for access to corporate networksin the workplace.Symbian OS is an open operating system, so by making IP protocolsavailable to application developers, a large number of new applicationsand services can be implemented.
Users have the ability to download andinstall new applications as they desire (possibly using IP for the downloadas well!), and operators and phone manufacturers can differentiate theirdevices by creating new IP-based services and applications for theirsubscribers.The purpose of this chapter is to enable you to implement IP-basedapplications, and make full use of the rich set of APIs available on SymbianOS. We also provide guidance on ensuring that the applications workwell over different bearer technologies, such as GPRS and WLAN.
Thischapter assumes that you have some prior knowledge or experience inusing IP protocols, and are familiar with the sockets interface as describedin Chapter 3.156IP AND RELATED TECHNOLOGIES6.1 IP Networks Overview6.1.1 An Overview of GPRSBefore we start on the Symbian OS-specific details, we’ll give a briefoverview of GPRS networks, as they may not be familiar to manydevelopers.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
