Project Final Report
Supervisor:
By:
Technion - Israel Institute of Technology
Faculty of Electrical Engineering
Software Systems Lab
Table of Content
Table of Content ........................................................................................................ 2
1. Introduction .............................................................................................................. 4
2. Project Contract – A Demands Document: ........................................................... 5
2.1 First phase: ....................................................................................................... 5
2.2 Second phase:................................................................................................... 6
2.3 Implementation: ............................................................................................... 6
3. Theoretical research: ............................................................................................... 7
3.1 Blue Tooth - General Information ....................................................................... 7
3.2 Network Model .................................................................................................. 12
3.3 Simulation issues ............................................................................................... 13
4. Network Statistics for Errors ................................................................................ 22
4.1.1 Errors caused by transmission interferences : ............................................. 22
4.1.2 Errors caused by over loading the pico-net (many users in a single piconet): ...................................................................................................................... 22
4.1.3 Delays caused by many pico-nets in a single area (collisions): ................. 22
4.2 Inside the lan: ..................................................................................................... 22
5. Conclusions ............................................................................................................. 24
6. Software design ...................................................................................................... 26
6.1 Network structure............................................................................................... 26
6.1.1 Opcode table ............................................................................................... 27
6.1.2 Client Activities .............................................................................................. 29
Opening connection ............................................................................................. 29
Touring in the museum ........................................................................................ 30
Sending Messages ................................................................................................ 31
6.1.3 Server Activities.............................................................................................. 32
Museum server ..................................................................................................... 32
6.1.4 HTTP server .................................................................................................... 32
6.2 Client software design........................................................................................ 33
Client Cache structure (class CCache) ................................................................. 35
6.3 Server software design ....................................................................................... 36
Server Data base structure(class CMuseum_db) ................................................. 38
7. Project main algorithms ........................................................................................ 40
7.1 Client Algorithms (class CClient_appApp) ....................................................... 40
7.1.1 Client connect and receive algorithm( StartSocket() ) ................................ 40
7.1.2 Client Send message algorithm (SendFifo()) .............................................. 41
7.1.3 Message Sender Algorithm (SendFifo()) .................................................... 42
7.2 Server Algorithms (CMserver) ...................................................................... 43
7.2.1 Connection Handler( ActiveListenning() ) ................................................. 43
7.2.2 Client handler Algorithm (ClientRun()) ..................................................... 44
7.2.3 Message handling Algorithm (ProccessMsg() ) ......................................... 45
7.2.4 Scalability of the main server – discussion ................................................. 46
Table of figures
Figure 3-1: Network model .......................................................................................... 12
Figure 3-2: Inquiry Times ............................................................................................ 19
\Figure 5-1: Network model......................................................................................... 25
Figure 6-1: network structure....................................................................................... 26
Figure 6-2 massage additional data.............................................................................. 28
Figure 6-3: Getting connected ..................................................................................... 29
Figure 6-4: room info procedure .................................................................................. 30
Figure 6-5: Messaging between clients........................................................................ 31
Figure 6-6:Client software layer model ....................................................................... 33
Figure 6-7: Client cache structure ............................................................................... 35
Figure 6-8: Srever software layer model ..................................................................... 36
Figure 6-9: Data-Base structure ................................................................................... 39
Figure 6-10: Client connect & receive algoritm .......................................................... 40
Figure 6-11: Client Send message algorithm ............................................................... 41
Figure 6-12: Message sender algorithm (client) .......................................................... 42
Figure 6-13: Connection hander Algorithm(client) ..................................................... 43
Figure 6-14: Client handler Algorithm ........................................................................ 44
Figure 6-15: Message handling algorithm(server) ....................................................... 45
1. Introduction
The museum project idea is to supply museum visitors a private guide to guide them
through their museum tour.
Every visitor of the museum will be able to rent a P.D.A at the entrance.
From this moment the visitor (our user) can interactively use the P.D.A as his private
guide.
The User is able to choose a tour by his field of interest.
The “Private Guide” will lead the User through the museum’s rooms while displaying
relevant information.
The information varies from the visitors current position, general information about
the museum and of course specific details about the different exhibits, all by User
demand.
Since people tend to visit museums gathered in groups in addition to the above our
“Private Guide” support features related to groups.
For example Users can send text Messages to other members of their group.
The way to achieve the above services is to build a wireless connection between the
P.D.A’s (the Users) and a museum server.
The sever holds a Data Base with all relevant information and manage connection
with the P.D.A’s (the clients).
Our first intention was to use “BlueTooth” technology for building the museum
wireless net.
Due to technical problems (will be detailed in this document) the museum net was not
implemented as a wireless net but as a LAN.
There for the final product is only a model of the wireless idea.
Still the final product demonstrates the main idea and can use as a base model for a
wireless implementation in the future.
2. Project Contract – A Demands Document:
2.1 First phase:
Server
The server application will be divided in to two sections:
Client features:
 Map – each client on connection to server will receive a
map of the museum rooms (format TBD).
Two possible map resolutions:
Big – picture of museum includes room numbers.
Small- picture of current room + the neighbor rooms.
 Room: subject of room + links to exhibitions.
 Exhibits: picture + text.
 General information: a map includes facilities like W.C,
cafeteria, shops etc.
Management & maintenance features
 Map control: maintenance of map feature.
 Room control: Add Room , Remove Room , Modify
Room.
 Exhibit control: Add Exhibit , Remove Exhibit ,
Modify Exhibit.
 Devices log: num of devices rented, billings, time of
rent, Last location & time of connection established.
Client

Map – each client on connection to server will receive a
map of the museum rooms (in format TBD).
Two possible maps resolutions:
Big – picture of museum includes room numbers.
Small- picture of current room + the neighbor rooms.



Room: subject of room + links to exhibitions.
Exhibits: picture + text.
General information: a map includes facilities like W.C,
cafeteria, shops etc.
2.2 Second phase:
Server




Client



Chat (text only): the possible connections are client-toclient, client to group (Server to Group/Client optional).
Each client will get a list of optional connections.
Groups: Add Group, Add Member, Remove Group,
Remove Member.
Choose a tour by field of interest: Will give the client a
list of optional tours and will guide him throw the tour
by pointing to next room.
Map additions : Zoom in on close environment (vector
graphic/metafiles – optional).
Where am I option – will show the client his position (a dot on the
right room).
Chat (text only): the possible connections are client to
client , client to group.
Each client will get a list of optional connections.
Choose a tour by field of interest : Will give the client a
list of optional tours and will guide him threw the tour
by pointing to next room.
Map additions : Zoom in on close environment (vector
raphic/metafiles).
Where am I option – will show the client his position (a dot on the
right room).
2.3 Implementation:
1. The GUI will be implemented in MFC & ATL .
2. The server will be implemented in C/C++ on Visual C++ environment
on WIN2K.
3. The client side will be implemented in C/C++ on Visual C++
embedded environment on WIN-CE.
3. Theoretical research:
Most of information in this section is arranged in a Questions – Answers format.
These questions supply us with most of the relevant information for designing the
net's simulation.
The material is arranged by these subjects:
1. Blue Tooth - General Information.
2. Network Model
3. Simulation issues:
 BT - Modes of operation.
 Net Topology.
 Times &
Rates in
the net.
 Efficiency of the net.
 Network Statistics for
Errors.
 Server Demands.
4. Conclusions & Ideas.
3.1 Blue Tooth - General Information
Bluetooth Device Personalization
Original Post: Personalization (SIG Forum) Date: 2000-08-15
One issue with Bluetooth is how it would be personalized. How do you stop the
situation of someone else changing the channel on your TV with my PalmPilot, or
from turning off your air conditioning with my thermostat? Basically how are
individual Bluetooth products different from everyone else's
The simple answer is that each Bluetooth equipped device has its own very unique
number called a Bluetooth Device Address, (BD_ADDR). Also when a piconet is
formed, each Slave unit is assigned a number called an active member address
(AM_ADDR).
Say somebody sends a Bluetooth command using his PalmPilot which is picked up
by your TV, (assume your TV is a slave in your house piconet). The TV won't
recognise the BD_ADDR if the PalmPilot is not in the same piconet, or will discard
the packet if the AM_ADDR doesn't match. Therefore your TV won't change channel
by the PalmPilot. Also various security features have been built in to ensure no
unauthorised tampering and packet modifying.
Obtaining BD_ADDR Values
Original Post: BD_ADDR ( eGroups Msg.) Date: 2000-09-13
Each Bluetooth device is allocated a unique 48-bit Bluetooth device address
(BD_ADDR). This number is obtained by contacting the IEEE to get an OUI that
forms 24bits of the 48bit address. You can apply for a further OUI when more
BD_ADDR values are required.
Full details are available in the 'Qualification Program Reference Document'.
Range
Q: What is the range of the BlueTooth transmitter?
A: The range is about 10m.
Bluetooth Range in Relation to Different Power Classes
Original Post: Range question (SIG Forum)
Date: 2000-03-27
Three power classes are available for bluetooth. Classes 1,2 & 3 , they have the
following characteristics:
Device
Power
Class
Max
Output
Power
(mW)
Max
Output
Power
(dBm)
Expected
Range
(?Obstructed
Environment?)
Class 1
100mW
20dBm
100m
Class 2
2.5mW
4dBm
10m
Class 3
1mW
0dBm
10cm
A definitive definition of ranges based on power class is hard to come. Not only due
to power & device differences but whether you measure open space or close office
See the Bluetooth overview at www.CambridgeSiliconRadio.co.uk for a simple
calculation of the range. In the Cambridge Silicon Radio overview the range in an
unobstructed scenario is about 30m for a 0dBm unit. The 10 m value is after
accounting for obstructions like walls.
It is important to note however that range is not just a function of power but of
receiver sensitivity as well. Digianswer have shown BT PC-Cards can reach a
100meter range in an unobstructed environment.
Handover/Handoff of Units Between Bluetooth Networks?
Original Post: Bluetooh Hand-off/Hand-over (SIG Forum) Date: 2000-04-27
Question
Does Bluetooth support handover/handoff between units in the same network, or
units between different bluetooth networks?
Answer
Bluetooth (as it currently stands) does NOT support handover/handoff between
Bluetooth piconets. If a device is in danger of loosing it's link to one master, no
provision is made to transfer it to another master.
Bluetooth has two types of networks, piconets & scatternets. Piconet is a net with one
master and many slaves, therefore handover is not possible here, as in order to stay
within the network, a slave would have to keep the same master. So by your definition
intra-handoff is not possible
Scatternets is where the problem is, many masters, and even more slaves, all
connected in different ways, masters in one piconet being slaves in other piconet and
so on. The thing is even if a slave is connected to a few masters, communication can
only take place from a particular master to a slave. The problem then is even if you do
handover a slave from one master to another, you have no way of sending the original
information to the transferred slave, unless you start to try to formulate a global
bluetooth network, which sends data by BD_ADDR etc. This is certainly not covered
by the Bluetooth specification, and likely it will never be, as the Specification just
covers the design of a short-range radio link, not the networks built on top of it .
There are a few reasons why Bluetooth does not support handover/handoff,
including




The purpose of BT is for cable replacement and adhoc network. It is
not really for mobile network or wireless LAN.
Reduce cost. Don't put everything on a small unit, remember BT is for
extra low cost wireless link (expected under $5 per node), it is
supposed to be very simple, efficient & small.
Technically speaking, every BT can be a Master or Slave, the piconet
formed by the Master is very dynamic,thus it is hard to define the
roaming boundary.
As Bluetooth piconets are designed to be dynamic and constantly
changing, a device moving out of range of one master and into the
range of another should be able to establish a new link in a reasonably
short period of time (typically between 1-5 seconds, depending on
factors such as timing, device history etc.)
However, although it is not defined in the spec, I personally think it is possible (I
examined one possible way of doing it in my FYP) but it will be vendor-dependent
which might have problems in interoperability.
Handover/Handoff might be useful with LAN Access Points. Assuming you have
many Bluetooth LAN access point (base stations) in somewhere (office, big house,
restaurant...) , in this case roaming and hand-off might be useful for having a seamless
connection. However, for Wireless LAN application, it seems IEEE802.11 may
be more suitable for this type of application.
Power Consumption for Different Modes
Original Post: Power Consumption (SIG Forum)
Date: 2000-05-14
Power consumption for the different modes , such as "Page Scan", "Park" and "Hold"
depend on:
The technology and circuit techniques used (Data sheet of the device) and, more
important,
What the intervals are? (What Scan Mode? Park- and Hold-interval?)
From the data sheet and the desired timing for the various modes, you can calculate
the average power consumption for that mode. Generally, about 60(+- 15)mA for
Receiving or Transmitting; about 20-30 uA in Standby mode (only the LPO runs).
Default Check Initilization (DCI) Value
Original Post: DCI Date: 2000-05-27
The DCI (Default Check Initilization) value is defined to be 0x00 (hexadecimal), i.e.
zero
When no common UAP is available in the transmitter and receiver, i.e. for the FHS
packet (in inquiry response state), then the DCI value is used as the common
UAP.
Difference Between Page and Inquiry
Original Post: Difference Between Page and Inquiry (SIG Forum)
Date: 2000-0611
Page is used to contact a Bluetooth unit you already know the BD_ADDR and
inquiry is to request the BD_ADDR of units in the area
The units in range can (or don't have to) respond to the inquiry. The units responds
with their BD_ADDR and the CLK so the inquiry unit can have knowledge on the
address and the clock of those units which respond to the inquiry. After that the
connection can be established (by then using the Page command).
Page Scan Termination
Original Post: (eGroups) Date:
If the bluetooth unit is in the (scan) R0 mode, it is supposed to perform continuous
scan .However it does not mean it will stays in page scan state forever until paged.
In this case the upper layer (e.g., LM) or application layer will decide to quit the
"page scan" after a certain period. The LC can not function independently without
getting intructions from LM.
Bluetooth Capacity & Throughput
Original Post: Bluetooth Capacity & Throughput (SIG Forum)
Bluetooth can support:



Date: 2000-03-16
an asynchronous data channel,
up to three simultaneous synchronous voice channels, or
a channel which simultaneously supports asynchronous data and
synchronous voice.
Each voice channel supports 64 kb/s synchronous (voice) link in each direction. The asynchronous
channel can support an asymmetric link of maximally 723.2 kb/s in either direction while permitting
57.6 kb/s in the return direction, or a 433.9 kb/s symmetric link. See transmission speed table below.
Note: D stands for Data , M stands for Medium rate , H stands for High rate
(All rates are in Kbits/sec)
Max
Max Forward
Packet Type Symmetric
(Assymetric)
rate (two way) rate
Max
Reverse
(Assymetric)
rate
DM1
108.8
108.8
108.8
DH1
172.8
172.8
172.8
DM3
258.1
387.2
54.4
DH3
390.4
585.6
86.4
DM5
286.7
477.8
36.3
DH5
433.9
723.2
57.6
AUX1
185.6
185.6
185.6
Maximum number of active users on one piconet is 7 plus the master. Can have
special 'parked' slaves - and many of them. To find data on the efficiency of BT
versus number of users see the www.iir-bluetooth.com site. In countries where they
use 79 hopping frequencies (USA and parts of Europe) obviously there is a (basic)
1/79 chance that you will collide with another piconet. An increased no. of piconets
means an increased chance of collisions.
Other countries only use 23, so 1/23 chance. You must also be aware that there are
some packets which span 5 times the normal slot size, so the chances of this type of
packet being involved in a collision is higher.
Power Control
(O) LMP_incr_power_req , LMP_decr_power_req , LMP_max_power ,
LMP_min_power
If the RSSI value differs too much from the preferred value of a Bluetooth device,
it can request an increase or a decrease of the other device’s TX power. Upon receipt
of this message, the output power is increased or decreased one step. At the master
side the TX power is completely independent for different slaves; a request from one
slave can only effect the master’s TX power for that same slave.The power
adjustment requests can be made at anytime following a successful baseband paging
procedure. If a device does not support power control requests this is indicated in the
supported features list.
3.2 Network Model
The Network model we are using is based on TCP/IP.
Built on a model which resembles the connection to LAN in Bluetooth,
The LAN access model is the objective that we want to accomplish.
Here will show a similar the protocol stack to the one we will build our program on it.
Are App
The
PDA
The
Server
The Wall Section
Figure 3-1: Network model
LAP – LAN Access Point (the device which will be a master in a pico net –sits in the
wall)
Each one of the PDA that will connect to the server opens a Data Terminal (DT) with
the server, Multiple DTs use a LAP as a wireless means for connecting to a Local
Area
Network (LAN). Once connected, the DTs will operate as if they were connected
to the LAN via dial-up networking. The DTs can access all of the services
provided by the LAN. The DTs can also communicate with each other
via the LAP. This is the network model in a nut shell, for more explicit explanation
refer to the "bloetooth profiles book" part K9.
3.3 Simulation issues
By the information we got from the "networks lab" experiments with BT
devices are still in the stage of two devices only.
No piconets were actually tested so far in this lab.
There for most of the information we gathered here is theoretical and
based on literature only.
BT - Modes of operation
Enabling Limited Discoverable Mode
Original Post: Limited Discoverable Mode (eGroups Msg.)
Date: 2000-11-03
A Limited Discoverable Mode is available for use by devices, and should be used
by devices that need to be discoverable only for a limited period of time, during
temporary conditions or for a specific event. The purpose is to respond to a device
that makes a limited inquiry. However there are no HCI command which orders a
directly device to go into Limited Discoverable Mode. Therefore it must be done
indirectly.
First of all, you set the desired IAC - Inquiry Access Code(s) (GIAC or DIAC) by
using Write_Current_IAC_LAP command. Then,every time your baseband enters
Inquiry_Scan state (p98 Baseband Specs), it scans only specified by that command
IAC(s). Once the IAC matched, the baseband goes to Inquiry_Response and responds
with an FHS packet.
Therefore, your device filters out non-matched IACs and "discovers" itself only to
those that matched.
Switch of Master-Slave Role
(O) LMP_switch_req , LMP_slot_offset
Since the paging device always becomes the master of the piconet, a switch of the
master-slave role is sometimes needed. Suppose device A is slave and device B is
master. The device that initiates the switch finalises the transmission of the current
L2CAP message and then sends LMP_switch_req. Note: in a slave initiated masterslave switch the slave (A) will first send LMP_slot_offset, then LMP_switch. In a
master initiated master-slave switch, the master (B) will first send LMP_switch,
before receiving LMP_slot_offset from the slave (A). If the switch is accepted, the
other device finalises the transmission of the current L2CAP message and then
responds with LMP_accepted. The switch procedure then takes place, and afterwards
device A is master and device B is slave.
Name Request
(M) LMP_name_req , LMP_name_res
LMP supports name request to another Bluetooth device. The name is a userfriendly name associated with the Bluetooth device and consists of a maximum of 248
bytes coded according to the UTF-8 standard. The name is fragmented over one or
more DM1 packets.
Detach
(M) LMP_detach
The connection between two Bluetooth devices can be closed anytime by the
master or the slave. A reason parameter is included in the message to inform the other
party of why the connection is closed.
Hold Mode
(O) LMP_hold , LMP_hold_req
The ACL link of a connection between two Bluetooth devices can be placed in hold
mode for a specified hold time. During this time no ACL packets will be transmitted
from the master. The hold mode is typically entered when there is no need to send
data for a relatively long time. The transceiver can then be turned off in order to save
power. But the hold mode can also be used if a device wants to discover or be
discovered by other Bluetooth devices, or wants to join other piconets. What a device
actually does during the hold time is not controlled by the hold message, but it is up to
each device to decide.
Sniff Mode
(O) LMP_sniff_req , LMP_unsniff_req To enter sniff mode, master and slave
negotiate a sniff interval T sniff and a sniff offset, D sniff , which specifies the timing
of the sniff slots. The offset determines the time of the first sniff slot; after that the
sniff slots follows periodically with the sniff interval T sniff . When the link is in sniff
mode the master can only start a transmission in the sniff slot. Two parameters control
the listening activity in the slave. The sniff attempt parameter determines for how
many slots the slave must listen, beginning at the sniff slot, even if it does not receive
a packet with its own AM address. The sniff timeout parameter determines for how
many additional slots the slave must listen if it continues to receive only packets with
its own AM address.
Park Mode
(O) LMP_park_req , LMP_unpark_PM_ADDR_req ,
LMP_unpark_BD_ADDR_req , LMP_set_broadcast_scan_window ,
LMP_modify_beacon
If a slave does not need to participate in the channel, but still should be FHsynchronized, it can be placed in park mode. In this mode the device gives up its
AM_ADDR but still re-synchronizes to the channel by waking up at the beacon
instants separated by the beacon interval. The beacon interval, a beacon offset and a
flag indicating how the first beacon instant is calculated determine the first beacon
instant. After this the beacon instants follow periodically at the predetermined beacon
interval. At the beacon instant the parked slave can be activated again by the master,
the master can change the park mode parameters, transmit broadcast information or
let the parked slaves request access to the channel.
All PDUs sent from the master to the parked slaves are broadcast. These PDUs are
the only PDUs that can be sent to a slave in park mode and the only PDUs that can be
broadcast. When a slave is placed in park mode it is assigned a unique PM_ADDR,
which can be used by the master to unpark that slave.
Setting Discoverable Modes
Original Post: Question on Discoverable Modes ... ( eGroups Msg.) Date: 2000-11-14
There are 3 types of discoverable modes:
General discoverable: The Bluetooth unit will send inquiry responses to all inquiries
from remote devices.
Limited discoverable: The Bluetooth unit will send inquiry responses only to
inquiries from remote devices that use one or more specific IACs (see the baseband
chapter on Channel Control).
Non-Discoverable: The Bluetooth unit never enters inquiry scan mode and will
therefor never send inquiry responses
Entering General or Limited discoverable mode is accomplished using the HCI
command HCI_Inquiry or HCI_Periodic_Inquiry_Mode and adjusting which LAP
value which generates the inquir.
Methods of Unparking a Slave Device in Park Mode
Original Post: Park Mode query (eGroups Msg. 141 ) Date: 1999-12-20
When a slave device is in park mode, it can request access to the channel through
the access window. After having sent an access request, the parked slaves will listen
for an unpark message from the master.
Now unpark messages can only be send in the beacon slots. But according to the
beacon access window structure the next beacon slot would only arrive after Maccess
access windows have passed by. This would mean that the slave would perform
repeated attempts in all the subsequent access windows, but still won't get a
response(unpark message) from the master.
Question
However the beacon access window also shows a master to slave slot. The question
is, would the master use this slot to unpark the slave, and if so, does this not conflict
with the explanation that the "master would unpark the slaves ONLY in the beacon
slots" ?
Answer
The answer is on page 120, sections 10.8.4.5 and 10.8.4.6 .
The master will use the beacon slot to unpark a slave ONLY if it is a master initiated
unpark.
In the case of slave initiated unpark, the master can unpark the particular slave using
broadcast packets in the master to slave slots in the access window.
This is logical because in the case of master initiated unpark, the master cannot be
sure whether the intended slave is listening to it during the access window. On the
other hand, it can be absolutely sure that the intended slave is listening to it at the
beacon instants because all parked slaves are supposed to listen to the master at least
at the beacon instants. For a slave initiated unpark, the master can be sure that the
slave which had sent a request to unpark, would be listening to it during the access
window. So in this case, the master can send an unpark message to the slave during
the access window itself, (the first paragraph on page 121 makes this clear).
Net Topology
Q: How many clients can we put in a single piconet ?
A: Each piconet can hold up to 7 active clients simultaneously and only one master.
Q: Can i restrict the broadcast to say 4 out of the 7 slaves?
A:Strictly speaking no, as the master can communicate with only one slave or all of
slaves at a time.However if Layers above L2CAP want to sent a message to a group
of devices in the piconet then, probably L2CAP can solve this problem, as the layers
above it do not understand the piconet concept.
Q: Is it possible to position more than one piconet in the same room?
A: Yes, each pico net has its own frequency hoping pattern so collision can be
overcome.
Q: If one piconet is limited to 7 slaves what do I do if I need to run 100 slaves? More
masters?
A: One way is to place slaves in park mode. You can have max. 255 or practically
unlimited number of parked slaves for a piconet. Note, however, that park mode is
only for ACL-links. Another way is to have many piconets. You have then to take in
account interference's, conflicts,... between them, increased retransmissions and
degraded data rate.
Question
How does the device schedule itself (figure out which piconet to service/listen)? .For
example ,there may be slots in which the device has obligations on BOTH piconets.
Answer 2 :
The specs say that slaves can participate in different piconets on a time-division
multiplex basis, but don't elaborate. I would say depending on whether a slave is
active/parked etc. if would spend different amounts of time with different masters,
with the highest priority (amount of time) on a particular piconet if it is an active slave
on that piconet. If it was a parked slave on a different piconet it would only switch to
that piconet on a beacon -slot. Hold & sniff modes would have higher priority that
park, but lower than active. Obviously some beacon slots, slave-to-master slots etc.
will be missed but this should be expected
Question:
Does the device need to save any internal state information regarding the piconets
when switching from one to another? Is this a function of the device hardware (a
finite save stack)? what exactly (beside change the hop sequence parameters) must a
device do to switch to another piconet on which it is an active member?
Answer:
The unit has to save all the important parameters like FLOW, ARQN, SEQN, the state
of the unit before it switched etc. You can do whatever you want to implement it, but
I think software (like an data structure in C to store) would be easier.
Slave initiated Communication/Slaves Polling Master?
Original Post: masters and slaves (eGroups Msg.) Date: 2000-07-24
In Bluetooth, a slave can only transmit to a master if it has been directly addressed in
the preceding master to slave slot. But how does an asynchronous event (such as UI
event info) initiated on a slave device get transmitted back to the master? Does this
mean that all Bluetooth applications must be supported by a simple "polling"
paradigm? A general observational answer:
The Slave must wait until it is polled by the Master then respond.All the
communication from slave to master will be through pre allocated slots or through
POLLing or in the slots preceded by the master to slave slot to that slave. Once
connected, the devices may switch the Master-Slave roles at any time, if it is required.
Or it can initiate a new piconet in which he is the Master so he can do whatever he
wants (a relative term, compared to being a Slave). But this approach has to invoke
page/page response step to form a new piconet (Inquiry/Inquiry Response is not
necessary since they already know each other).
Master-Slave Combinations/ Network Change Possibilities
eGroups Messages :
The Master-slave topology can cause some problems , here is an example of a
scenario and their answers Note: There can be just one master in a piconet, further a
communication is always initiated by the master.
Scenario:
3 Masters X,Y,Z are within the same room(within 10 meters)...theoretically we have 3
active piconet and 21 potential active slaves within this room.
Event:
Device S comes in...and wants to become a slave to the masters X,Y,Z,
Solution:
A
If the new device S wishes to take a pro-active role in joining the piconet, it can
issue a page/inquiry to master X (actually all master would receive the page/inquiry,
which master responds first is irrelevant, let us assume master X responds first) , and
ask for a communication, the master X will respond as slave and then S and X can
switch their roles as master & slave so that S has now joined X's piconet. After this is
done the above procedure will be repeated for Y and Z. The AM_ADDR's of all
devices will be updated after each network change.
B
If the new slave wishes to take a re-active role, if can go into the inquiry scan state
or page scan state. The page scan state would only be entered if device S believed that
one of the master had encountered S before and was now seeking to page S again.The
length of the scan state (Inquiry/Page) would depend on the priority of the desired
connection. I.e if device S required to be contacted as soon as possible, it could stay in
inquiry scan mode for as long as it deemed necessary . Eventually one of the master
would contact device S , and it would join the piconet. After a while device S, should
become a slave to all 3 masters.
Conclusion:
Which approach to take obviously depends on the urgency of the device, and the
situation of the networks. If speed and control is needed, solution A would be
preferable. If simplicity and a non-critical application are the features of the device S,
solution B might be better.
Using a single AM_ADDR to Communicate to Multiple Slaves?
Original Post: groups (eGroups Msg. ) Date: 2000-09-21
One question occasionally asked is whether it is possible to assign one AM_ADDR
to a couple of (group) of slaves and thus send one message (i. e. a command) to these
devices simultaneously
It is not possible to assign a multiple slave specific AM_ADDR , the baseband can
only assign one AM_ADDR per slave (otherwise we could have more than seven
active slaves per master).Instead there is a group abstraction in the L2CAP layer
which resolves to a group of CIDs (local Channel identifiers), which in turn represent
a number of BD_ADDRs.
Times & Rates in the net
Q: What is the transmission rate of the Bluetooth?
A: the transmission rate is divided in to three sections:
1. server to client: 723.2 Kbps
2. client to server: 57.6 Kbps
3. simultaneously: 433.9 Kbps
The DH5 packet may cover up to five time slot and 266.6 Tx/Rx will be possible.
1600 hops / (5 (Foward) + 1 (Reverse)) = 266.6666
So total data rate for fowarding is as follows:
339byte(Max Payload) * 8bit * 1600 / 6 = 723200 bps = 723.2kb/s
TX/RX Turn-around time Definition
Original Post: Definition of "Tx-Rx turn around time" (SIG Forum) Date: 2000-0215
Within Bluetooth theDefinition of 'Tx-Rx turn around time' is:
The time it takes for a BT-device to go from transmitting (TX) to listening (RX).
In that time interval the device does not send and does not listen
Bluetooth Bit Rate: Raw versus Actual
Original Post : how is it the bit rate? (SIG Forum) Date: 2000-03-28
In the spec, the modulation rate is defined as 1M symbol per second [1Ms/s]. The
symbol rate equals the bitrate since the modulation within Bluetooth is Gaussian FSK.
Therefore the raw bitrate available is 1Mbit/s .
If the BT protocol is used, the highest net (actual ) rate obtainable in asymmetrical
mode is 723kbit/s (DH5 packet)
This max obtainable bitrate is lower than the raw bitrate because of several factors:



Bluetooth maximum of a 5 slot packet, which can carry 339 bytes of
payload (2712 cycles).
However, this also requires a 72 cycle access code, and a 54 cycle
packet header, and a 16 cycle CRC code. This is a total of 2854 cycles
for just 339 bytes of information.
Then we have another hop which takes up 625 cycles, before we can
send another packet.

So for each 3750 cycles, we are transmitting only 339 useful bytes of
data.
Given that we have 1Mbit/s to play with, that's 266 packets / second, or 723,200 bytes
per second. This means we are wasting over 27% of our bandwidth for
acknowledgement and for frequency hopping.
Scanning Issues for a Device in Inquiry Scan State
Original Post: Inquiry Scan state question (eGroups Msg. ) Date: 2000-01-05
Question
When a BT device enters Inquiry Scan mode, the spec (1.0A) says it will listen for
a minimum of 18 slots at a given frequency. Does this mean that the device will listen
in both its TX and RX slot times? Or does it use a mechanism like the HOLD
exteTime Taken to complete Inquiry/Paging Procedures
Original Post: Identifying Slaves (SIG Forum) Date: 2000-04-06 ,
Original Post: Questions - minimum time required (eGroups Msg. 124)
Date:
1999-12-01
The Baseband Specs can be very confusing in giving definite minimum/maximum
times used in Inquiry & paging operations between devices, with the result that there
have been a lot of speculation what these time are. In the lack of experimental data,
below is what the theory says SHOULD be the time taken to complete a typical
average successful Inquiry & Page operation, and thus the typical times taken to setup
a Bluetooth Link..
Operation Minimum Average
Type
Time
Time
Maximum
Time
Inquiry
0.00125s 3-5s
10.2430.72s
Paging
0.0025s
1.28s
2.56s
Total
(paging
+inquiry)
0.00375s
4.285.28s
12.833.28s
Figure 3-2: Inquiry Times
An inquiry train must be repeated at least 256 times (2.56s duration) , before the
other train is used. Typically, in an error-free environment, 3 train switches must take
place. This means that 10.24s could elapse unless the inquirer collects enough
responses and determines to abort the procedure. However, during a 1.28s probing
window, a slave on average responses 4 time, but on different frequencies and at
different times.
Minimum Inquiry Time
A minimum time for an inquiry operation is 2 slots (1.25ms). This is where the
master transmits an inquiry message at the f(k) frequency in the beginning, the
slave scans the inquiry at the f(k) frequency at the same time. So, the slave
receives inquiry message in the first slot. The slave responses with a FHS packet
for the master's inquiry message in the next slot. So, in total 2 slots are needed.
This in highly unlikely though, as the slave will not respond after receiving the
first inquiry message but rather, wait RAND number of slots. This RAND value
varies between 0 and 1023 (Specs p111).
Average Inquiry Time
As stated above 10.24s could elapse unless the inquirer collects enough responses
and determines to abort the procedure. However practice has revealed that between 35 seconds is sufficient. This value can vary considerably depends on alignment of the
device clocks and their respective states
Maximum Inquiry Time
10.24 Seconds would be what the user would typically expect for a maximum
inquiry time, although the HCI specs give wait values up to a minute (amount of time
specified until the inquiry is halted). 30.72 seconds has been suggested as a maximum
time.
Paging Times
Assuming that you are using the mandatory paging scheme, and using page mode
R1(where each train is repeated 128 times, before switching to the other one ,
Baseband p 101), then the average time for connection should be 1.28s. The
maximum time for connection is 2.56s, during this , the A+ B train will have been
repeated 128 times each, and a response should be returned.
Note: in the specs it's not immediately apparent that the frequency change of the
page message (which changes every 1.28s) is unrelated to the train change time (also
1.28s). The frequency change does not mark a train change event.
Minimum Page Time
This is similar to the Minimum Inquiry Time. When the master transmits page
message at the f(k) frequency in the beginning, the salve scans the inquiry at the f(k)
frequency at the same time. So, the slave receives the page message in the first slot.
The salve responses with an ID packet for the master's page message in the next slot.
And then in the next slot the master transmits a FHS packet to the slave. Finally in the
next slot the slave answers. So, in total 4 slots are needed for the minimum (2.5ms).
Average Page Time
As stated above the average time for connection should be 1.28s. This is assuming
that the difference between the Bluetooth clocks of the master and the slave is
between 8x1.28s and +7x1.28s, and so one of the frequencies used by the master will
be the hop frequency the slave will listen to.
Maximum Page Time
As already stated , the maximum time will be 2.56s . During this time both A+ B
trains will have been repeated 128 times each, and a response should be returned.
nsion of the uncertainty period from +- 10uS to a larger number, say +-1250uS?
Answer
The TX and RX slots are determined by the master's clock. A device entering
Inquiry scan has no knowledge of the master's clock. So the concept of TX and RX
slots does not apply to a device in Inquiry scan. It scans continuously for 16 hop
frequencies (not 18) and when it receives an inquiry message, it performs the inquiry
response procedure. A device sending the inquiry message (master) however
transmits only in transmit slot and listens in receive slots. These slots are determined
by it's native clock. There is no extension of the uncertainty period
Efficiency
Question: Does the performance of the one piconet (on which the device serves as
master) simply suffer (i.e., no transmits) because the device is busy responding as
slave on the other piconet?
Answer: Yes the performance will be hit. First of all when it is in active mode as
slave in one piconet, it has to listen to the master of that piconet as it cant predict
when it may be polled. If a slave is participating in multiple piconets, it could remain
in active mode in only one piconet at a time and have to be in HOLD(preferably, as it
could retain the AM address) or PARKED mode in other piconets. In HOLD mode a
SCO link, if at all present, still remain supported. If a slave has a SCO link in one
piconet, it may not be able to form a SCO link in another piconet (I think so) as the
slots are pre allotted, the slots may overlap and the slots may not be aligned. But if a
device wants to have SCO links with 2 different devices, it may become master to
both so that it could decide which slots to allot
4. Network Statistics for Errors
In our project we will simulate the effects of the Bluetooth Error Rates in layers, the
problems will be divided into 2 major different sections inside / outside the pico-net.
4.1 Inside the piconet:
In this section we will also divide into different parts:
1.1. Errors caused by transmission interferences.
1.2. Errors caused by over loading the piconet(many users in a single piconet).
1.3. Delays caused by many piconets in a single single area(collisions).
4.1.1 Errors caused by transmission interferences :
According to the spec (BLUETOOTH SPECIFICATION Version 1.1 part A. sec.4)
the requirements for BER (raw error bit rate) is 0.1% which the interference in the air
4.1.2 Errors caused by over loading the pico-net (many users in a
single pico-net):
Didn’t find exactly but when more than 7 clients in a single pico net the master puts
some of the client in park mode in order to give service to all the clients in the piconet. When the master has clients which are waiting it clears one of the slots and
convert it into beacon time slot which is used to communicate with parking clients.
The delay caused by having more then six clients for each client is:
 time _ of _ service(changing _ client  service _ time)  (Total _ number _ of _ Clients  6)
4.1.3 Delays caused by many pico-nets in a single area
(collisions):
when having more then a single pico net in a single area we get collisions in the air,
the fact that each pico-net uses frequency hoping in a unique hoping algorithm
frequencies collide we calculated a crude way, for example the delay caused by
having 10 pico-nets in a single area is 66%, so a crude calculation for the delay is:
1
Delay  time _ of _ service  79
19


1  No _ of _ Pico  Nets   179  78 79


 

4.2 Inside the lan:
Inside the LAN we will not simulate since we are using LAN in are project.
Server Demands


The BT device transmission rates are about 1 Mbyte/sec.
A fast Ethernet transmission rate is about 100 Mbyte/sec.
70% * 100 = 70 M Byte/sec ---> 70 clients ---> 70 / 7 = 10 static devices per
server.
***Q: Assuming a computer was equipped with all bluetooth enabled
peripherals.How is this configured, as single/multiple piconet(s) , and thus who is
master and who is slave?
2 (slightly) differing answers given:
A1:The BT unit attached to the CPU should become the master and will control all
the slaves (which are peripherals). So that the BT at the CPU could contact all the
other devices without switching the piconet. If required, the devices may switch roles
at any time.
A2:The BT unit who wants to be Master becomes Master of the piconet it
formed. It is all up to the unit itself (perhaps controlled by the application
running on the unit).
5. Conclusions








The piconets will work in the Master – Slave format.
The static devices will be Masters, the clients will be Slaves .
Direct communication between slaves will not be allowed.
Each piconet build of one Master & 7 slaves.
Each piconet can hold up to ~200 clients in Park Mode (like sleep).
It is possible for a few piconets to work in the same room.
Each client will get it's own IP number on the net.
The client will get a new IP on each time it will become an active
member of a piconet.
 The static device (Master) will assign the IP for the client.
 Masters of each Room will have fixed IP numbers that belongs only to
the specific Room.
 In addition to IP each client will get a static ID (that will stay the same
during all the visit).
*** It is advisable to have a central unit for every few rooms in order to
decrease the transmission
over the net.
This unit will supply Data that deals with the few neighbor rooms.
(We repeatedly supply this data all the time with no changes).

how do we Know in which room we are ?
explanation: how do we know what is the id of a PDA, how does the
server know who sent the information?
Solution: We assume that each one of the LAP's (wall unit's) has 7 static IP's
which it can give to the PDA's connected to it, on connection or returning from PARK
mode (on park mode the PDA releases its IP ) the PDA gets a new IP.

It may cause a new problem: the number of IP's is limited and we might have
many rooms and in each room several PDA's.

Solution: Let say we have 1000 room's and in each room we have 3 LAP's
that about 21000 different IP's, in every MAC address we have
32 bits > 15 bits >log2(21000) - > we have enough IP’s.
** A flow chart of client modes of operations can be found in the next page !!!
Flow chart for client modes of operation in the pico-net
Entering
Active Mode
Client finished Request
Request for
Service
No Request for
Service wait Tout
Counter < Max_Aloud
Park Mode
System Not
Busy continue
getting
service
System is
Busy increase
Servie
Counter>Max_Aloud
Counter
Client made request for service
\Figure 5-1: Network model
6. Software design
6.1 Network structure
Museum
server
HTTP
server
2
Server
Server
1
LAN
4
3
Hub
Hub
5
Pico net
Pico net
PDA
PDA
HTTP
server
PDA
6
PDA
Figure 6-1: network structure
PDA
Museum
server
PDA
The network it built from several components
1. The Museum server – this server holds the data base and manages all
information requests from the clients and all the Messaging that is passed
between clients.
2. The Http server - contains the museum web pages for touring in the museum.
3. “Wall units” - also work like hubs, this units supply each connected client
network access and IP to use in the network, this units are connected to the
network from one side and from the other side they are connected to the
clients using Bluetooth.
4. LAN - the museum Local Area Network connects all the “Wall units” to the
server this is a wired network.
5. The Pico net - a Wireless network that connect the clients to the “Wall units”
this network run using Bluetooth technology, this networks are very distance
limited, so each room have at least one Pico net in it.
6. PDA’s – this are the clients, they go from one room to another moving from
one Pico net to another, in each Pico net they receive a local IP , after
disconnecting from a Pico net they roam and try to reconnect the wait time
between each try is 100ms so it doesn’t overload the network.
The network is destined to be based on Bluetooth and Ethernet; in this project we
based the network on LAN only using TCP/IP protocol.
Over the physical network we created a protocol of messages to assist us in
communicating between the clients and server this protocol could be expanded but we
limited it for the project needs only.
There are several messages all share the basic structure of the message described in
the next table.
6.1.1 Opcode table
Opcode(long)
1000
1010
1020
1030
Message
open connection
liveliness message
close connection
text message
1040
1045
1050
1055
room info
ROOM_INFO_RESP
group info
GROUP_INFO_RESP
Additional data
none
none
none
number
of
recipients(long),id0
of
recipients(long),id1,...,the
text message
none
room number
none
number of memberes, id0,name
0,id1,name 1,...
Table 1: Message Opcode table
In the next figure we describe how the massages look
Basic Message
command(long)
PDA id(long)
Additional data
Message length(long)
Text Message
Additional
data
=
Number of
recipients
ID of
recipient 1
ID of
recipient 2
...
Text Message
Group info resp Message
Additional
data
=
Number of
ID of
Name of
Members member 0 member 0
...
ID of
Name of
member N member N
Room info resp Message
Additional
data
=
Room
number
Figure 6-2 massage additional data
In messages the fields: PDA id, command, message length, number of recipients, ID
of recipients, ID of members and room number are used as long (32 bit).
All other information is char and not defined in length.
6.1.2 Client Activities
The activities of the client to the server are divided to initialization time and after
initialization time activities.
Opening connection
Opening connection to the server is a sequential activity built from 4 steps that at the
end of this steps the Museum server knows where the client in the present time.
And if we are initializing then we ask for our group info data
Museum
server
HTTP
server
Server
4
LAN
3
Hub
Hub
2
1
PDA
Pico
net
Pico
net
PDA
PDA
Figure 6-3: Getting connected
PDA
PDA
PDA
Connection steps
1. connect to wall
2. get IP
3. connect to museum server – if initializing send Group info request
4. Get waiting messages or if starting get Group info response
Touring in the museum
Touring in the museum involves the use of the two servers of the museum and is
available only on the client.
This activity is done only after selecting a tour. no room information will be available
before selecting the tour, when pressing on a link the client application addresses the
HTTP server directly.
In the project we united the two servers on a single server but it is possible to divide it
to 2 servers also.
HTTP server
Museum server
Server
3
2
4
1
PDA
Figure 6-4: room info procedure
1. Send a request for room info
2. Receive the a message saying what room your in .
3. Send Request to the HTTP server for pages
4. Down load and display pages
Sending Messages
Sending messages between clients is available also when sender or one of the
recipients is offline, the sender of the message writes the message and selects
recipients, if the sender is online then the message is sent immediately, else the
message is queued, when the client goes online the message is sent.
When the message reaches the museum server it adds the message to the recipient
message FIFO and activates a thread to send the message, if the recipient is online
then the message is passed immediately else the message is queued and whe the
recipient goes online then the message is passed.
Museum Server
1
3
2
PDA
PDA
Client 1
Client 2
Figure 6-5: Messaging between clients
Client 1 wants to send a message to client 2 who is in his group.
Assuming client 1 is connected:
1. Client 1 sends the message to the “Museum Server” addressed to client 2
2. If client 2 is connected then skip this stage, else when client 2 connects
3. The “Museum Server” send all waiting messages for client 2 to the client
6.1.3 Server Activities
Museum server
The museum server activities are built from several stages:
 initialization – in this stage the server loads all museum data from the
configuration file and initialize the Data-base of the museum, opens the socket
to start listening on the socket for incoming client, reset the data in the
Data-base
 Run time- runtime is divided in several activities in different layers
i.
Dialogs – in this part new users/groups are added/removed
ii. Socket – accepts request from the clients and implement them
iii. Data-base – addressed from the sockets and the dialog
 Termination – when the server terminates it frees all allocated memory and
exits
The server works all the time until it is shut down, modification in the rooms can be
done only when the server is turned off
6.1.4 HTTP server
The HTTP server is a regular http server that provides data on demand on
initialization the server must be set the root path for the museum web pages, all the
other data is a regular HTTP server data No special attributes.
6.2 Client software design
The client is basically divided into three layers shown in the next diagram
Application layer
Send
FIFO
Context manager
Receive
FIFO
COM layer
WAN - Pico net
Figure 6-6:Client software layer model
The layers are:
 Application layer(class CClient_appAppDlg) – contains all dialogs like the
main dialog, send messages, read messages, this layer receives request from
the user and converts the to activities like requesting information, sending text
messages, reading messages, navigating and all other activities done by the
user
 Context manager(class CClient_appApp) – this layer intermediates between
the lower layer that is the Socket layer and the upper layer that id the
application layer, it contains FIFO to handle messages for incoming or out
going, also manages the Web browsing request and retrieves files to a directed
path

COM layer(class CSocketLayerClient) - connect the physical layer that is
the Pico net(Wireless Area Network) to the FIFO layer, receives requests to
open/close socket send/receive data
Client Cache structure (class CCache)
The cache in the client is used for back navigation of the client’s web browser,
The Cache structure is unique since it combines 2 types of caches: LRU and an
option in which the page to be deleted from cache is the one that navigation back was
done from it.
The cache holds information on the few recent pages that were visited.
The cache is constructed as a hash table, each entry in the hash is of type class
template CList, the List of elements in an entry holds CString type.
Each entry in the cache leads to a list that contains the web page file names and all of
its relevant file names.
The first entry in a page list contains the html file name for the page and all the
following elements in the list are the associated files (pictures for example).
Checking whether a file exists in the clients memory is done by passing over the hash
entries and searching for the file’s name .
This structure is updated dynamically as long as the program runs.
The Cache is initialized as empty structure and also releases all its allocated memory
Before the program’s end.
The next diagram shows the cache structure.
HTML
page
Image
Image
Image
Cache
entry
HTML
page
Image
Image
Image
HTML
page
Image
Image
Image
HTML
page
Image
Image
Image
Cache
entry
Cache
entry
Cache
entry
Hash
table
File names
only
Figure 6-7: Client cache structure
6.3 Server software design
The Server like the client is basically divided into three layers shown in the next
diagram
Application layer
Museum manager
Client
handler
Data Base
Routing Layer
Connection
handler
Client
handler
COM Layer
LAN
Figure 6-8: Srever software layer model
The layers are:
 Application layer (class CServer_appAppDlg) – contains all dialogs like the main
dialog, add client, add group, remove client, remove group. This
layer
is
receives request from the administrator and updates the data base accordingly
 Routing layer (class CServer_appApp) – this layer intermediates between the
lower layer that is the Socket layer and the upper layer that id the application
layer, it contains the next components:
i.
Connection handler (class CMserver) – Receives a request to open the
connection with sever, it decides to accept or decline the request, if request
is accepted it creates a new for client handler thread .
ii.
Client Handler (class CMserver)– After accepting a connection this thread
is created, it is created for each client separately, for each client exists a
client handler, on connecting the client it updates the Data-base. Once a
client disconnects the thread self terminates and updates the Data-base that
the client disconnected. When the client is connected the client handler
manages requests and also provides service for sending text messages,
sending text messages to another client is done through the Data-base by
adding the message to the data base and activating the recipient Client
handler, if an handler for a client is already is active then the new handler
terminates it self.
iii. Data-Base (class CMuseum_db) – holds all data on the server and the
clients, also holds for each client a FIFO Queue for messages and local
information on the client the
Data-base can be replaced easily by an
SQL server by changing the implementation of the header files
 COM layer(class CSocketLayerServer) - connect the physical layer that is the
Pico net(Wireless Area Network) to the FIFO layer, receives requests to
open/close socket send/receive data
Server Data base structure(class CMuseum_db)
The server’s Data-base objective is to contain all relevant information for managing
the museum tour program.
The relevant information is divided into four main section:
 Client information
 Group information
 Room information
 IP information
The server data base is made to simulate an SQL data base and can be replaced easily
by one. The advantage of having an internal Data-base is that the internal Data-base is
much faster then a SQL server.
Data-base implementation
The Data-base is build of 4 different sub data bases one for each information type.
All sub Data bases are connected with the others through pointers from one to the
other.
Each sub data base is build as a hash table, in the following lines we describe the data
bases:
1. Client hash (class CClient) - holds a client information including group
number, a pointer to the IP class, next member in group, incoming messages
for the client etc..
2. Group hash (class CGroup) – holds pointer to the first client in the group, num
of members, group name etc.
3. Room hash (class CRoom) – holds room information, the name, pointer to the
IP’s in the room, room neighbors etc. .
4. IP hash (class CIP) – this hash has 256 entries, in each entry there is a linked list of
IP’s, the hash function is calculated by modulo of the lower 8 bits of the IP address,
each IP entry in the list has the next fields: IP, pointers to next IP in room and next IP
in list, room number etc..
The next diagram shows the sever Data-base structure
Data base structure
Data base
Client hash
Struct has the following
fields:
- name
- group number
- pointer to IP
- number of PDA
- Message fifo & mutex for it
- socket and management
flags for it
- group index
- current IP
- next member in group
Room hash
The Struct has the following
fields:
- name
- room number
- pointer to first IP in room
- List of neighbors
- exist
IP hash
Struct has the following
fields:
- IP
- room number
- pointer next IP in room
- pointer next IP in Hash
Figure 6-9: Data-Base structure
Group hash
Struct has the following
fields:
- name
- group number
- pointer to first client
- number of PDA’s in group
7. Project main algorithms
7.1 Client Algorithms (class CClient_appApp)
The client’s algorithms describe the main algorithms used by the client.
The algorithms are:
1. Connect and listen algorithm
2. Send message algorithm
3. Message sender algorithm.
7.1.1 Client connect and receive algorithm( StartSocket() )
Describes the client algorithm for opening a connection to the server and listening for
incoming messages.
The Algorithm is an infinite loop that always check if the client is connected to the
server and waits for incoming messages from the server. If it is not connected it
roams in order to connect.
Open connection
No
Activate Message
Sender
Yes
Am I connected?
Listen For a new
Message
Disconnected ?
Add Message to
receive FIFO
Figure 6-10: Client connect & receive algoritm
7.1.2 Client Send message algorithm (SendFifo())
This algorithm describes the process of sending a message from the client to the
Museum server.
Messages for send are received from the application (text/requests).
Every message for send is pushed into a Send FIFO Queue.
Adding a message to the FIFO is activating a sending handler.
Recived message to
send
Add message to send
FIFO
Activates message
sender
Figure 6-11: Client Send message algorithm
7.1.3 Message Sender Algorithm (SendFifo())
This algorithm describes the way of operation of the send message handler.
The handler checks if connection to server exists.
If there is a connection the
handler sends the message and removes it from the head of the send FIFO.
message
sender
Am I connected?
Send Message and
remove it from send
FIFO
No
Yes
Finish
Figure 6-12: Message sender algorithm (client)
7.2 Server Algorithms (CMserver)
1. Connection Handler Algorithm
2. Client handler Algorithm
3. Messages handling Algorithm
7.2.1 Connection Handler( ActiveListenning() )
This algorithm is responsible for establishing connection with the system’s clients.
In order to do so the server opens a listening socket.
The server listens for connection requests on this socket only.
When ever it gets a connection request the server opens a private socket for the new
client and creates a thread that handles the new client’s acceptation (ClientRun).
Active listen module
(ActiveListenning())
Start server
Listen On socket
No
Received a new
connection
Yes
Figure 6-13: Connection hander Algorithm(client)
Start thread
of client
handler
(ClientRun())
7.2.2 Client handler Algorithm (ClientRun())
This thread waits for messages to be received from the client.
After receiving a message the thread checks if the client’s status is initiated in the
Museum Data Base, if not it updates the client’s status in Data Base and activates the
client’s messages sender (in order to send the messages that are waiting for this
client).
Start client handler
Receive Message
header
If client Not
initiated exit else
Disconnect client
and exit
No
Is in header in
correct size?
Yes
Get client and
message info from
header
Exit Thread
set client status
connected in Database and start the
client Messenger
No
No
Get Message
Additional data
Got Data O.K. ?
Is client
Initiated
Yes
Yes
Figure 6-14: Client handler Algorithm
Process Message
7.2.3 Message handling Algorithm (ProccessMsg() )
This algorithm is responsible for decoding the received messages and act accordingly.
Received
Message
Group info
Case on message:
Room info
Collect room info
from Data Base
Text message
Build a group info
response message
Unknown
For each target in
the text message
targets
Build a room info
response message
Make a copy of the
original message
Add the message
to the requestor
FIFO and activate
it’s messenger
Add the message
to the target FIFO
and activate it’s
messenger
End loop
Delete original
message
Finish
Figure 6-15: Message handling algorithm(server)
Add the message
to the requestor
FIFO and activate
it messenger
7.2.4 Scalability of the main server – discussion
As mentioned earlier after establishing connection with a client the server opens a
private socket for the new client and creates a thread that handles the new client’s
acceptation and further processes.
As a result of this behavior of the server every client demands its own thread that
actually exists as long as it is connected to server.
The above design works great as long as system serves a small number of clients.
When we increase number of clients to a few hundreds the operation system will have
difficulties dealing with an enormous number of threads at the same time and will
eventually crash.
A possible solution for this problem is using a ‘Threads Pull’.
In this way the operation system allocates all our clients a limited number of threads.
The clients will share these threads as common recourses.
If number of clients is bigger than number of threads the clients will wait till a thread
resource will be ready to serve them.
Due to the fact that clients are not active all the time but demand service only once in
a while this way of operation is possible.
Since our project was designed for the lab’s conditions we didn’t use the ‘Threads
Pull’ method.
Scalability can be achieved by making some changes in the main server.