Symbian OS Communications (779884), страница 19
Текст из файла (страница 19)
It provides serial port emulation, including various flow controlmechanisms. It cannot provide error control itself, so it relies on L2CAPto provide reliability. As previously discussed, it is preferable that L2CAPuses its own error control mechanism to provide reliability, rather thanBLUETOOTH TECHNOLOGY OVERVIEW79requiring the ACL to stay in reliable mode, as this allows RFCOMM tocoexist with time-sensitive data on the same link.RFCOMM is based on the GSM 07.10 protocol, which in turn is basedon the HDLC protocol. HDLC provides the underlying frames that areused during RFCOMM connection setup, teardown and data exchange.GSM 07.10 adds an ‘internal’ protocol to allow the exchange of controlmessages between RFCOMM multiplexers to configure channels attachedto the multiplexer, send test commands, apply flow control etc.
Note that,although the 07.10 protocol allows for the non-multiplexed exchangeof data (the so-called ‘disconnected mode’), this is not supported inRFCOMM.Since the protocol provides a simple datalink, there are not a greatdeal of user services other than the provision of a byte pipe. However,there are some features available that merit discussion due to RFCOMM’sability to emulate a serial connection.The flow control mechanisms in RFCOMM are:5.Per-channel stop/go flow control between RFCOMM entities.6.Multiplexer stop/go flow control between RFCOMM entities.7.Per-channel credit-based flow control between RFCOMM entities.8.RTS/CTS emulated RS-232 flow control between applications usingRFCOMM.9.DTR/DSR emulated RS-232 flow control between applications usingRFCOMM.10.XON/XOFF emulated RS-232 flow control between applicationsusing RFCOMM.Notice that the first three of the flow control mechanisms are appliedbetween RFCOMM entities, not the applications using RFCOMM.
Thusthe application cannot directly stop or start the data flow. The final threeare effectively ways for applications to believe they are using an RS-232cable using standard flow control mechanisms. The RFCOMM entities donot honour the flow control signals in these cases – they merely conveythem to the peer applications.
Since a wireless technology has a muchhigher latency than RS-232 it is of questionable benefit for an applicationto rely on the emulated flow control to actually perform flow control.Instead, it is far better for the application to delegate flow control to thosebuilt into RFCOMM (mechanisms 1–3 above).Other emulated RS232 services provided by RFCOMM include theability to configure emulated port settings such as baud rate, number ofdata and stop bits, parity etc. Again, RFCOMM does not honour thesesettings – so, for example, it does not throttle the data sent betweenRFCOMM entities to match the emulated baud rate. The settings are80BLUETOOTHmerely conveyed so that applications can believe they are running overan RS-232 link.4.1.8 PortsBoth L2CAP and RFCOMM are connection-oriented multiplexing protocols; thus each requires the service to consider on which port it wishes toreceive connections over which to transport the service’s data.There are subtle semantic differences between L2CAP and RFCOMMports that should be noted.L2CAP portsL2CAP ports are called ‘protocol service multiplexers’, or PSMs.
Theyallow multiple channels from the same device to be connected to thesame PSM; each time an L2CAP connection is created from a device to aremote PSM, the remote L2CAP entity assigns a unique channel identifier(independent from the PSM) to the connection (this identifier is hiddenfrom the application, but the RSocket forms a handle to it).
There is noconcept of a ‘source’ PSM, unlike TCP and UDP, which have the conceptof source ports.Different multiplexers handle connections to or from other remotedevices (there is one multiplexer in the Symbian OS L2CAP implementation per remote device) so there is no risk of collision betweenchannel identifiers from different devices. This is also transparent to theapplication, and does not change the way PSMs are handled.The range of L2CAP port numbers is split into two parts by the L2CAPspecification: those below 0x1001, which are reserved by the BluetoothSIG, and those greater than or equal to 0x1001 which are available tousers.
Another rule regarding PSM values is that the final octet must havethe least-significant bit (lsb) set. The L2CAP specification actually allowsPSMs to be extended beyond 16 bits (by clearing the lsb of the secondoctet) – however Symbian OS, as with many other implementations, doesnot support this. Of course this still leaves around 30,000 ports available!It is important to note that L2CAP ports in the user range are never‘well known’, unlike many services using TCP and UDP which typicallypublish their port. The reason for this is that SDP allows the port valueto be retrieved dynamically. The corollary of this is that an applicationrunning over L2CAP should not register using a hard-coded port.
Toaid dynamic port selection, there is a mechanism for the application torequest a free port from the local L2CAP entity. This is an importantfeature for running applications both over a protocol that does not usewell-known values and on an open platform such as Symbian OS, wheremany such applications may be present.Note that if your service requires more than one channel – for exampleto carry two different traffic types – then you could connect them toBLUETOOTH TECHNOLOGY OVERVIEW81the same PSM. This is how the Bluetooth A2DP profile operates – ituses multiple connections to the same port, with the sequence of theconnections indicating the purpose of that channel.
In this case SDP doesnot provide a mechanism to indicate either the purpose of the differentconnections, or the quantity of connections required – these rules arestatically held by the service implementations. In most circumstancesthough it is preferable to use multiple ports, because using the order inwhich the connections are made to determine the purpose of the channelcan add a great deal of complexity. However, as is the case with A2DP,there are occasionally some situations in which it is useful to multiplexonto the same port (the result being that Bluetooth baseband packets canbe filled more completely).RFCOMM portsRFCOMM ports are called ‘server channels’. Unlike L2CAP PSMs, they donot allow multiple channels on the same port between two given devices.This is because there is no dynamically assigned channel identifier thatis independent from the server channel (actually, there is a channelidentifier that can be a different value to the server channel, but it is notindependent from the server channel).Like L2CAP, there is an RFCOMM multiplexer per remote device inSymbian OS.
Therefore as channels are identified by a (source address,destination address, server port) tuple, there is no problem with differentremote devices connecting to the same server channel.As with L2CAP, SDP is always used to retrieve port numbers for agiven service – therefore there are no well-known ports in RFCOMM.Again, as with L2CAP, the RFCOMM protocol in Symbian OS provides amechanism for the application to obtain a free server channel.Unlike L2CAP, RFCOMM has far fewer ports: indeed only around 30;with no reserved/user split. A number of the RFCOMM server channelswill already be in use after the Symbian device has booted; these will belistening for connections from Bluetooth headsets, for receiving objectsusing the OBEX protocol, or for receiving connections to enable thedevice to act as a Bluetooth modem.The RFCOMM specification does allow an increase in the number ofports available to a local device, however, RFCOMM is considered asomewhat ‘legacy’ protocol now that L2CAP is gaining more features thatallow any form of service to be developed and therefore Symbian OSdoes not implement this feature.When to Use L2CAP or RFCOMMSince L2CAP and RFCOMM are both datalink protocols, there is adecision to be made as to which should be used when implementing aBluetooth service.82BLUETOOTHThe advantage of RFCOMM is that it is guaranteed to provide a flowcontrol service individually to each service, unlike L2CAP which canonly do this when both ends of the link support L2CAP 1.2 or greater.It also provides an RS-232 emulation service, but the need for that innewly developed wireless services is arguably non-existent.
RFCOMM isalso guaranteed to provide a reliable service to its clients – however, itdoes this in a way that can impact other services running on the samedevice. A final advantage is that for some services the stream interface ofRFCOMM may be useful, although it is trivially easy to simulate a streamprotocol using the L2CAP sequenced packet service.The advantage of L2CAP is that it is, by definition, a lighter-weightprotocol because it has removed the extra connection setup, and frameheaders and trailers that are yielded through the use of RFCOMM (whichis, of course, running over L2CAP).If you can be sure that the two devices running your service will beusing Symbian OS v8.1 and later, then you can rely on the availability oferror and flow control services at the L2CAP layer – so there is no needto use RFCOMM to obtain these services. Furthermore, the SAR servicewithin L2CAP 1.2 will help to maintain better protocol performance ofmany independent Bluetooth services. L2CAP can make certain higherlayer protocols easier to implement through its datagram semantics.
Ofcourse, the service can provide a shim over L2CAP sockets to makethem appear as a stream interface if it so desires. Finally, L2CAP has agreater number of ports, and possesses more sophisticated semantics forthe support of multiple connections.It should be noted that a service may choose to use L2CAP andRFCOMM at the same time: it might make sense to have a ‘control’channel using L2CAP to exchange the service’s control messages, butto use RFCOMM – to the same service on the same remote device – tosend bulk data.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
