Hi,
We have the following test scenario: 2 fixed nodes (a sender and a receiver) A and D and 2 mobile nodes, B and C, moving between them. B and C start from A and D respectively and move towards each other. They are in contact for a short duration in between A and D. When they are in contact, they do not have any contact with the fixed nodes. We send data from A and use the mobile nodes to carry the bundles to D.
The configuration we were using is epidemic routing and we send a file of 12MB, fragmented proactively in 1MB payload size.
At the sender, we get 12 bundles of 976.7K and 1 bundle of 569.3K. We assumed that the same number of bundles with identical sizes will be at the receiver. However, after all the bundles have been delivered at the receiver, we see that there are 11 bundles of 976.7K, 1 bundle of 12.1K and one bundle of 540.1K.
Is it normal for there to be a discrepancy in the bundle sizes on both sides? If so, why is there a difference? Note that we do not run the dtninbox application on the receiver side to extract the file to the application layer.
It would be great if you could also give us a short description of how epidemic routing is implemented in your code.
Regards, Sandra
Am 14.03.2014 18:30, schrieb Sandra Siby:
Is it normal for there to be a discrepancy in the bundle sizes on both sides? If so, why is there a difference? Note that we do not run the dtninbox application on the receiver side to extract the file to the application layer.
If fragmentation is enabled and a TCP convergence layer is used reactive fragmentation is also activated. Thus, the additional fragment may be a result of the reactive fragmentation triggered by an interrupted connection.
It would be great if you could also give us a short description of how epidemic routing is implemented in your code.
The routing modules iterate through the storage and select bundles to forward on each contact following some selection constrains. For details I suggest to read the commented code (yes, it is commented!).
https://github.com/ibrdtn/ibrdtn/blob/master/ibrdtn/daemon/src/routing/epide...
Kind regards, Johannes Morgenroth
Hello Johannes,
Thank you for the reply.
Note that there is no 'additional fragment'. There is an equal number of fragments on both sides but their size distribution is different. And if you add up the sizes of fragments obtained on the receiver side, it is less than the total at the sender side. In other words, I think the entire file is not sent. I am unable to extract the file to the application layer.
Any idea why this is the case?
Regards, Sandra On Mar 17, 2014 1:54 PM, "Johannes Morgenroth" morgenroth@ibr.cs.tu-bs.de wrote:
Am 14.03.2014 18:30, schrieb Sandra Siby:
Is it normal for there to be a discrepancy in the bundle sizes on both sides? If so, why is there a difference? Note that we do not run the dtninbox application on the receiver side to extract the file to the application layer.
If fragmentation is enabled and a TCP convergence layer is used reactive fragmentation is also activated. Thus, the additional fragment may be a result of the reactive fragmentation triggered by an interrupted connection.
It would be great if you could also give us a short description of how epidemic routing is implemented in your code.
The routing modules iterate through the storage and select bundles to forward on each contact following some selection constrains. For details I suggest to read the commented code (yes, it is commented!).
https://github.com/ibrdtn/ibrdtn/blob/master/ibrdtn/daemon/src/routing/epide...
Kind regards, Johannes Morgenroth
-- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
Hello Sandra,
in this case is have no concrete idea. There might be a possible hash collision in the summary vector bloom-filter, but this is very unlikely. What about the contact times? Were they long enough to transmit all the bundles? The bundles with the wrong size may be a result of interrupted connections.
Did you checked the daemon log output for errors or warnings? You could check the exact behavior using the log files. Did you run the test a second time with the same result? And finally, which version of the daemon do you use? There are known bugs in the 0.10.2 related to fragmentation (fixed in development branch).
Kind regards, Johannes
Am 17.03.2014 14:33, schrieb Sandra Siby:
Note that there is no 'additional fragment'. There is an equal number of fragments on both sides but their size distribution is different. And if you add up the sizes of fragments obtained on the receiver side, it is less than the total at the sender side. In other words, I think the entire file is not sent. I am unable to extract the file to the application layer.
Any idea why this is the case?
participants (2)
-
Johannes Morgenroth -
Sandra Siby