cengwins / ahc Goto Github PK

Hello, under what license is this project released under ? I would like to study it to learn from it. Thank you.

Describe the bug
I got type error when I tried to use print_forwarding_table method of Topology class.

Traceback (most recent call last):
  File "D:/Projects/ahc/tests/testmutualexclusion.py", line 64, in <module>
    main()
  File "D:/Projects/ahc/tests/testmutualexclusion.py", line 34, in main
    topology.print_forwarding_table()
  File "D:\Projects\ahc\Ahc.py", line 329, in print_forwarding_table
    print('\n'.join([''.join(['{:4}'.format(item) for item in row])
  File "D:\Projects\ahc\Ahc.py", line 329, in <listcomp>
    print('\n'.join([''.join(['{:4}'.format(item) for item in row])
TypeError: 'int' object is not iterable

To Reproduce

1. Use Topology().print_forwarding_table() or topology.print_forwarding_table().

Expected behavior
I was expected to see forwarding table of the topology.

Modules
Ahc module, Topology class, print_forwarding_table method.

Desktop:

• OS: Windows 10 (64-bit)
• Python version: 3.8.8 within Anaconda environment with PyCharm

Additional context
I managed to fix the problem with the following lines:

  def print_forwarding_table(self):
    registry.print_components()
    digits = int(math.log10(len(self.nodes) - 1) + 1)   # Assuming node ids are integers and starting from 0 to n.
    digitsFormat = '{:' + str(digits + 1) + '}'   # +1 is for spacing character between node ids in forwarding table.
    print('\n'.join([''.join([digitsFormat.format(destination) for destination in self.ForwardingTable[source]])
                     for source in self.ForwardingTable]))

Describe the bug
The broadcast message header in the Broadcasting file results to the default sequence number instead of the unique broadcast id. This results in each broadcast message having the same id.

To See
Where does this occur?

1. Go to the Broadcasting file
2. Scroll down to the senddownbroadcast function
3. Exactly when defining the header at hdr = BroadcastingMessageHeader(BroadcastingMessageTypes.SIMPLEFLOOD, whosends, destination, nexthop, interfaceid, sequencenumber).

To Reproduce
Try Broadcasting a message using Controlled flooding.

Expected behavior
Each broadcast message should have a unique identifier given to it when the on_broadcast function is triggered and determined by the "self.uniquebroadcastidentifier".

Desktop:

• OS: Mac OS
• Python version 3.9

Workaround
Adding a dummy interfaceid as follows should solve the problem
interfaceid = float('inf')
hdr = BroadcastingMessageHeader(BroadcastingMessageTypes.SIMPLEFLOOD, whosends, destination, nexthop, interfaceid, sequencenumber)

Describe the bug
Higher layer packets that pass through the broadcast service on the way up to the corresponding layer are not properly processed. This makes it impossible for the receiving layer to demultiplex the packet.

Reproducing the error
Steps to reproduce the behavior:

1. Create a broadcast message, say from the application layer.
2. Send it down to the necessary layers, do some multiplexing and send it down to the broadcast service.
3. In the broadcast service do the necessary multiplexing.
4. Send down for onward delivery to recipient.
5. The receiving node will send the received packet up to the necessary layers and trigger the senddown broadcast once again.
6. The senddown broadcast expects an event from the on_message_from_buttom module, but it gets a payload.
7. Therefore, the next node the receives this forwarded broadcast will receive a broadcast message encapsulated in another broadcast message, which it sends to the corresponding upper layer.
8. The receiving layer receives a broadcast message encapsulated in another broadcast message instead of one, resulting in an error.
9. Decapsulating the two will not solve the problem, because there can be further rebroadcasts, from the same node.

Expected behavior
The broadcast service when forwarding a broadcast message should only forward the message without further encapsulation. Or decapsulate the message and send it once again. So that a higher level layer receiving a broadcast message can be able to access the payload meant for it after a single decapsulation.

Modules
The issue above is related to the following modules in the Broadcasting.py file
senddownbroadcast()
on_message_from_bottom()

Desktop (please complete the following information):

• OS: Mac OS Catalina
• Python version 3.9

Additional context

The senddownbroadcast() function expects an event with the necessary payload to forward. Therefore, replacing

self.senddownbroadcast(eventobj, eventobj.eventcontent.header.messagefrom, eventobj.eventcontent.header.sequencenumber)
with
event = Event(self, BroadcastingEventTypes.BROADCAST, payload)
self.senddownbroadcast(event, eventobj.eventcontent.header.messagefrom, eventobj.eventcontent.header.sequencenumber)
should solve the problem.

Even though sending the payload as below seems feasible, it doesn't work because senddownbroadcast() expects an event.

self.senddownbroadcast(eventobj.eventcontent, eventobj.eventcontent.header.messagefrom, eventobj.eventcontent.header.sequencenumber)