Systems编程设计讲解、辅导Java程序、c++程序调试 讲解留学生Prolog|辅导Web开发
- 首页 >> Python编程 Network Systems Integration Project - Scuba Chat
March 30, 2021
1. Objective of the integration project
Design and implement a fully distributed multi-hop ad-hoc chat application using
emulated wireless sound communication among at least 4 nodes (underwater chat
devices).
2. Details
The final integration project of Module 3 will be performed in groups of 4 students. The
goal is to design and implement the networking and application functionality for an
underwater chat application.
The chat application should be distributed and ad-hoc, i.e., it should not rely on a server
to manage connections and routing data packets among clients. The underlying physical
layer that you have to use is one based on wireless sound communications. In some
situations, e.g. underwater, the propagation of (electromagnetic) radio waves is extremely
poor. In some of these situations, wireless communications using sound waves may be
possible, be it at rather low data rates. Your chat application should use wireless
communications using sound waves, utilizing a physical layer provided by us (hence the
name scuba chat).
To allow for remote/online development, testing, and demoing, the physical layer
framework we make available supports emulated sound communications using an
Internet connection to our emulation server, which ”transmits” messages to other nodes
within the emulated range, tuned to the same channel. You will use this emulator during
development and testing. It also has to be used during your final demo.
Please consider the following issues while designing your solution:
● You need to design and implement a multi-hop ad-hoc network mechanism to
communicate at least 4 nodes, all of them running on different laptops and using
either the emulated
(https://canvas.utwente.nl/courses/7856/pages/framework-for-physical-layer) or
sound-based physical layer
(https://canvas.utwente.nl/courses/7856/pages/audio-communication-framework)
that we provide.
● Your chat service has to support reliable text broadcasting, i.e. text messages of
arbitrary length typed in any of the nodes should be delivered identically and in
the correct order to all other nodes.
● Your system should run on a single sound channel (frequency). Multiple channels
(frequencies) have been defined so that different groups can run their systems
without interfering with each other. Please find the formula to calculate your
channel frequency in http://netsys.ewi.utwente.nl/integrationproject/.
● You will have to design a mechanism for addressing.
● You will have to design a mechanism for medium access control.
● As in the real world, the range of the sound-based physical layer is rather limited,
you will have to come up with some forwarding mechanism to also exchange
packets between nodes that can reach each other only via one or more intermediate
nodes. Please note that in the emulator, the position, and hence connectivity of the
nodes can be set using the web-interface we provide.
● As in the real world, the sound-based physical layer is quite error-prone, you will
have to design a protocol for reliable data transfer.
● You need to ensure the order of sent messages at the receiving node.
● Any node in the chat application should be able to see which other nodes are
present and reachable.
● Think about the user interface (but do not invest too much time in making it
fancy).
3. Hints for getting started
You have to design and implement the system above using a sound-based physical
layer that we provide. There are two variants of this physical layer. The first one
will use your laptop’s loudspeaker and microphone to wirelessly send and receive
information using sound. Because we do not want you to sit together with your
groupmates in the same room (to avoid the risk of Corona infection), we make
available the means for emulated sound communication. This latter variant is
using a server we provide, and which you communicate to using the standard
networking facilities of your laptop.
Your program will have to connect to either the audio software or emulation
server. This will be handled for you by a small framework you can download from
Canvas (in either Java or C++). Both frameworks provide you with a queue in
which received messages will appear and a queue for data frames you want to
transmit. There are 2 messages you can send and 6 you can receive. These
messages are specified below.
Sending:
● DATA: With this message, you can send a frame of 32 bytes of data. The
framework will handle sending this to the audio interface or emulation
server, you just have to provide the bytes. If the number of bytes provided
is less than the frame length (32 bytes), the frame will be padded with
random bytes. If the number of bytes provided is more than the frame
length, the excess bytes will be discarded.
● DATA SHORT: With this message, you can send a short frame of 2 bytes
of data. If the number of bytes provided is less than 2 bytes, the frame will
be padded with random bytes. If the number of bytes provided is more than
2 bytes, the excess bytes will be discarded.
Receiving:
● BUSY: You will receive this when the channel becomes busy.
● FREE: You will receive this when the channel becomes free.
● DATA: You received a data frame, this message will contain data as bytes
(specifics depending on your programming language).
○ Note: a data frame will be received by all nodes within the
transmission range and listening to the channel of a transmitter, only
if no other node within the interference range of the receiver does a
transmission on the same channel overlapping in time.
● DATA SHORT: You received a short data frame, this message will contain
data as bytes (specifics depending on your programming language).
● SENDING: A frame has started being transmitted. You can send multiple
frames during transmission, which will be queued. You will receive this
message when each of them starts transmitting.
● DONE SENDING: You will receive this when all queued frames have
been Transmitted.
Example:
We have node A and node B, they are in the range of each other. A starts sending a
frame (DATA), it will receive SENDING and BUSY. When the data has been
transmitted it will receive DONE SENDING and FREE. During the same time
node B will have seen BUSY around the same time node A received this. B will
receive DATA and FREE once A’s transmission is complete.
You can use the webpage http://netsys.ewi.utwente.nl/integrationproject/ to view and
manipulate the (emulated) positions of your nodes and see if they are transmitting. The
help page can be found in http://netsys.ewi.utwente.nl/integrationproject/help/.
4. What to deliver?
Each group needs to deliver the following for the integration project of the module
Network Systems:
● Give a demo of your designed system:
During the final demo, you demonstrate the features of your chat
application. It is expected that you will be able to at least demo the
following features of the application:
- A simple user interface
- Presence/reachability information
- Reliable text messaging (broadcasting), even in the presence of
packet drop (emulated by our server)
- Multihop forwarding of messages to nodes only reachable via
intermediate nodes
● Submit a final report on your project: The final report should be
submitted via Canvas. Please hand in your report as a .pdf file.
● Submit the source code of your system: The source code of your project
has to be submitted in a .zip file using Canvas.
March 30, 2021
1. Objective of the integration project
Design and implement a fully distributed multi-hop ad-hoc chat application using
emulated wireless sound communication among at least 4 nodes (underwater chat
devices).
2. Details
The final integration project of Module 3 will be performed in groups of 4 students. The
goal is to design and implement the networking and application functionality for an
underwater chat application.
The chat application should be distributed and ad-hoc, i.e., it should not rely on a server
to manage connections and routing data packets among clients. The underlying physical
layer that you have to use is one based on wireless sound communications. In some
situations, e.g. underwater, the propagation of (electromagnetic) radio waves is extremely
poor. In some of these situations, wireless communications using sound waves may be
possible, be it at rather low data rates. Your chat application should use wireless
communications using sound waves, utilizing a physical layer provided by us (hence the
name scuba chat).
To allow for remote/online development, testing, and demoing, the physical layer
framework we make available supports emulated sound communications using an
Internet connection to our emulation server, which ”transmits” messages to other nodes
within the emulated range, tuned to the same channel. You will use this emulator during
development and testing. It also has to be used during your final demo.
Please consider the following issues while designing your solution:
● You need to design and implement a multi-hop ad-hoc network mechanism to
communicate at least 4 nodes, all of them running on different laptops and using
either the emulated
(https://canvas.utwente.nl/courses/7856/pages/framework-for-physical-layer) or
sound-based physical layer
(https://canvas.utwente.nl/courses/7856/pages/audio-communication-framework)
that we provide.
● Your chat service has to support reliable text broadcasting, i.e. text messages of
arbitrary length typed in any of the nodes should be delivered identically and in
the correct order to all other nodes.
● Your system should run on a single sound channel (frequency). Multiple channels
(frequencies) have been defined so that different groups can run their systems
without interfering with each other. Please find the formula to calculate your
channel frequency in http://netsys.ewi.utwente.nl/integrationproject/.
● You will have to design a mechanism for addressing.
● You will have to design a mechanism for medium access control.
● As in the real world, the range of the sound-based physical layer is rather limited,
you will have to come up with some forwarding mechanism to also exchange
packets between nodes that can reach each other only via one or more intermediate
nodes. Please note that in the emulator, the position, and hence connectivity of the
nodes can be set using the web-interface we provide.
● As in the real world, the sound-based physical layer is quite error-prone, you will
have to design a protocol for reliable data transfer.
● You need to ensure the order of sent messages at the receiving node.
● Any node in the chat application should be able to see which other nodes are
present and reachable.
● Think about the user interface (but do not invest too much time in making it
fancy).
3. Hints for getting started
You have to design and implement the system above using a sound-based physical
layer that we provide. There are two variants of this physical layer. The first one
will use your laptop’s loudspeaker and microphone to wirelessly send and receive
information using sound. Because we do not want you to sit together with your
groupmates in the same room (to avoid the risk of Corona infection), we make
available the means for emulated sound communication. This latter variant is
using a server we provide, and which you communicate to using the standard
networking facilities of your laptop.
Your program will have to connect to either the audio software or emulation
server. This will be handled for you by a small framework you can download from
Canvas (in either Java or C++). Both frameworks provide you with a queue in
which received messages will appear and a queue for data frames you want to
transmit. There are 2 messages you can send and 6 you can receive. These
messages are specified below.
Sending:
● DATA: With this message, you can send a frame of 32 bytes of data. The
framework will handle sending this to the audio interface or emulation
server, you just have to provide the bytes. If the number of bytes provided
is less than the frame length (32 bytes), the frame will be padded with
random bytes. If the number of bytes provided is more than the frame
length, the excess bytes will be discarded.
● DATA SHORT: With this message, you can send a short frame of 2 bytes
of data. If the number of bytes provided is less than 2 bytes, the frame will
be padded with random bytes. If the number of bytes provided is more than
2 bytes, the excess bytes will be discarded.
Receiving:
● BUSY: You will receive this when the channel becomes busy.
● FREE: You will receive this when the channel becomes free.
● DATA: You received a data frame, this message will contain data as bytes
(specifics depending on your programming language).
○ Note: a data frame will be received by all nodes within the
transmission range and listening to the channel of a transmitter, only
if no other node within the interference range of the receiver does a
transmission on the same channel overlapping in time.
● DATA SHORT: You received a short data frame, this message will contain
data as bytes (specifics depending on your programming language).
● SENDING: A frame has started being transmitted. You can send multiple
frames during transmission, which will be queued. You will receive this
message when each of them starts transmitting.
● DONE SENDING: You will receive this when all queued frames have
been Transmitted.
Example:
We have node A and node B, they are in the range of each other. A starts sending a
frame (DATA), it will receive SENDING and BUSY. When the data has been
transmitted it will receive DONE SENDING and FREE. During the same time
node B will have seen BUSY around the same time node A received this. B will
receive DATA and FREE once A’s transmission is complete.
You can use the webpage http://netsys.ewi.utwente.nl/integrationproject/ to view and
manipulate the (emulated) positions of your nodes and see if they are transmitting. The
help page can be found in http://netsys.ewi.utwente.nl/integrationproject/help/.
4. What to deliver?
Each group needs to deliver the following for the integration project of the module
Network Systems:
● Give a demo of your designed system:
During the final demo, you demonstrate the features of your chat
application. It is expected that you will be able to at least demo the
following features of the application:
- A simple user interface
- Presence/reachability information
- Reliable text messaging (broadcasting), even in the presence of
packet drop (emulated by our server)
- Multihop forwarding of messages to nodes only reachable via
intermediate nodes
● Submit a final report on your project: The final report should be
submitted via Canvas. Please hand in your report as a .pdf file.
● Submit the source code of your system: The source code of your project
has to be submitted in a .zip file using Canvas.