## 3 Proposed Model
### Model Phases
```
1.CoreRoutingPhase():
2.InitializeOutputBuffer()
3.For each message in buffer:
4.DetermineMessageDestination()
5.ProcessMessageForOutputBuffer()
6.InitializeOutputBuffer():
7.Create an empty temporary output buffer
8.DetermineMessageDestination():
9.Identify whether message's destination is the connected node or another node in the network
10.ProcessMessageForOutputBuffer():
11.If message's destination is another node:
12.DetermineNodeMeetingTimes()
13.CopyMessageToOutputBufferBasedOnCriteria()
14.DetermineNodeMeetingTimes():
15.Calculate time elapsed since current node met destination (x) and since other node met destination (y)
16.CopyMessageToOutputBufferBasedOnCriteria():
17.If current node did not meet destination while other node did:
18.Copy message to output buffer
19.Else if current node met destination while other node did not:
20.Exclude message from output buffer
21.Else:
22.If x < y:
23.Exclude message from output buffer
24.Else:
25.Copy message to output buffer
```
**Algorithm 3**Non-Deliverable messages

During this synchronized process, the current phase operates at the sender's side, while the subsequent phase executes at the receiver's side. Initially, the sender compiles the metadata of all messages stored in the output buffer into a single message, which is then transmitted to the receiver. This metadata includes the message ID and its size. Subsequently, the sender waits for a response from the receiver for each message. Upon receiving the response, the sender decides whether to proceed with sending the message or remove it from the output buffer based on the received reply. It is important to note that the receiver's responses are determined by specific criteria outlined in the fifth phase of the protocol. As illustrated in Algorithm 4, the sender remains in a waiting state until a reply is received from the receiver. Each reply message issued by the receiver contains either \"RCV_OK\" or \"DENIED_LOW_RESOURCES\", along with the corresponding message ID for which the reply is provided. If the receiver responds with \"RCV_OK\", the sender dispatches the message from the output buffer whose ID matches that in the reply message and then returns to the waiting state. Conversely, if the reply is \"DENIED_LOW_RESOURCES\", indicating insufficient resources at the receiver, the connection between the sender and receiver is terminated. ```
1. SynchronizedDataExchangePhase():
2.SenderSideProcessing()
3.ReceiverSideProcessing()
4.SenderSideProcessing():
5.GatherMetadataOfMessage()
6.CreateMetadataMessage()
7.TransmitMetadataMessageToReceiver()
8.WaitForResponseFromReceiver()
9.ProcessReceiverResponse()
10.ReceiverSideProcessing():
11.WaitForMetadataMessage()
12.ExtractMetadataFromMessage()
13.SendResponseForEachMessage()
14.GatherMetadataOf/Messages():
15.For each message in output buffer:
16.Extract message ID and size
17.Store metadata in temporary structure18.CreateMetadataMessage():
19.Construct a message containing metadata of all messages in output buffer
20.TransmitMetadataMessageToReceiver():
21.Send metadata message to receiver
22.WaitForResponseFromReceiver():
23.Wait for reply from receiver
24.ProcessReciverResponse():
25.If response is RCV_OK:
26.SendMessageFromOutputBuffer()
27.Else if response is DENIED_LOW_RESOURCES:
28.CloseConnectionWithReceiver()
29.WaitForMetadataMessage():
30.Wait for metadata message from sender
31.ExtractMetadataFromMessage():
32.Extract message IDs and sizes from metadata message
33.SendResponseForEachMessage():
34.For each message metadata:
35.EvaluateResponseCriteria()
36.Send appropriate response to sender
37.EvaluateResponseCriteria():
38.If sufficient resources available:
39.Respond with RCV_OK
40.Else:
41.Respond with DENIED_LOW_RESOURCES* **Phase 5: Message acceptance criteria** During this phase, which occurs at the receiver's side following the receipt of message metadata sent by the sender in the preceding phase, a series of actions unfolds.