Hi dear list!
I was wondering if it is possible to use two different routing protocol among a network.
The easiest one I can think, and fastest to deploy, of is: - One dynamic routing protocol (BATMAN, spray-and-wait, prophet...) - One static routing protocol based on destination, i.e., all bundles with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards, --- Auzias Maël auzias.net http://www.auzias.net/en/ - vcard http://www.auzias.net/auzias.vcf - thesis http://people.irisa.fr/Mael.Auzias/ *GSM: 0033 695 118 774*
Hello Maël
Not sure what MEB is, but currently IBR-DTN does not support configuring different routing protocols at once with one exception: I think even with Prophet or Epidemic enabled, static routes are honoured. So in a hacky way, this could be used to forward bundles to another statically configured neighbour, that runs another routing protocol (possible on different TCPCL ports and Discovery addresses), so basically you build n separate DTN networks/overlays , with each one using a different routing, and make sure there is no auto discovery between the two, and use static routing to transfer bundles between the two overlays. Not too flexible, and more complexity, but it „should work“(tm).
Sebastian
On 07 Sep 2015, at 14:55, Maël Auzias ibrdtn@auzias.net wrote:
Hi dear list!
I was wondering if it is possible to use two different routing protocol among a network.
The easiest one I can think, and fastest to deploy, of is:
- One dynamic routing protocol (BATMAN, spray-and-wait, prophet...)
- One static routing protocol based on destination, i.e., all bundles with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! 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 Sebastian,
thanks for your answer. I'm just wondering: If I "make sure there is no auto discovery between the two" how does my first node will forward the bundle to the other close by node on the different overlay if they don't discover each other?
By reading your answer I thought about running two local IBR-DTN daemon (is it at least possible?) and each of them process a different algorithm. Not the most efficient way, but on the idea it „should work“(tm).
Anyway, thanks again !
Best regards, --- Auzias Maël auzias.net https://www.auzias.net/en/ - vcard https://www.auzias.net/auzias.vcf - thesis http://people.irisa.fr/Mael.Auzias/ *GSM: 0033 695 118 774*
On Wed, Sep 9, 2015 at 9:22 PM, Sebastian Schildt schildt@ibr.cs.tu-bs.de wrote:
Hello Maël
Not sure what MEB is, but currently IBR-DTN does not support configuring different routing protocols at once with one exception: I think even with Prophet or Epidemic enabled, static routes are honoured. So in a hacky way, this could be used to forward bundles to another statically configured neighbour, that runs another routing protocol (possible on different TCPCL ports and Discovery addresses), so basically you build n separate DTN networks/overlays , with each one using a different routing, and make sure there is no auto discovery between the two, and use static routing to transfer bundles between the two overlays. Not too flexible, and more complexity, but it „should work“(tm).
Sebastian
On 07 Sep 2015, at 14:55, Maël Auzias ibrdtn@auzias.net wrote:
Hi dear list!
I was wondering if it is possible to use two different routing protocol
among a network.
The easiest one I can think, and fastest to deploy, of is:
- One dynamic routing protocol (BATMAN, spray-and-wait, prophet...)
- One static routing protocol based on destination, i.e., all bundles
with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on
how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! 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.
Hi,
exactly, you can run two (or more) local IBR-DTN daemons if they are using different ports for API and TCP-CL and different discovery addresses. Between the different overlays you can only transmit data statically, i.e. on a node with two DTN daemons running under different ports, you can add one as static neighbour to the other and use some static routes to „lift“ bundles from one overlay to the next. Probably there are a million pitfalls doing this, but it could work :) I used something similar (two daemons on one node) when I wanted to interconnect a IEEE 802.15.4 DTN (no flooding, no discovery) with a noisy IP-based DTN (many nodes, Prophet, lots of traffic), to avoid DoSing the 802.15.4 network.
Sebastian
On 10 Sep 2015, at 07:21, Maël Auzias ibrdtn@auzias.net wrote:
Hello Sebastian,
thanks for your answer. I'm just wondering: If I "make sure there is no auto discovery between the two" how does my first node will forward the bundle to the other close by node on the different overlay if they don't discover each other?
By reading your answer I thought about running two local IBR-DTN daemon (is it at least possible?) and each of them process a different algorithm. Not the most efficient way, but on the idea it „should work“(tm).
Anyway, thanks again !
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774
On Wed, Sep 9, 2015 at 9:22 PM, Sebastian Schildt schildt@ibr.cs.tu-bs.de wrote: Hello Maël
Not sure what MEB is, but currently IBR-DTN does not support configuring different routing protocols at once with one exception: I think even with Prophet or Epidemic enabled, static routes are honoured. So in a hacky way, this could be used to forward bundles to another statically configured neighbour, that runs another routing protocol (possible on different TCPCL ports and Discovery addresses), so basically you build n separate DTN networks/overlays , with each one using a different routing, and make sure there is no auto discovery between the two, and use static routing to transfer bundles between the two overlays. Not too flexible, and more complexity, but it „should work“(tm).
Sebastian
On 07 Sep 2015, at 14:55, Maël Auzias ibrdtn@auzias.net wrote:
Hi dear list!
I was wondering if it is possible to use two different routing protocol among a network.
The easiest one I can think, and fastest to deploy, of is:
- One dynamic routing protocol (BATMAN, spray-and-wait, prophet...)
- One static routing protocol based on destination, i.e., all bundles with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! 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.
-- !! 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.
Dear Sebastian, Concerning multiple DTN daemons, it may be of some interest to share my little experience with multiple daemons of different DTN implementations with IBR DTN users and maintainers. You can install both ION and DTN2 on the same machine, but if you switch on both, you have problems. This means that you have to duble check that the other daemon is off before switching on the wanted one. The same is basically true also for IBR-DTN and the others two. With IBR-DTN and DTN2 the problem is worsened by the fact that the IBR daemon is named "dtnd" exactly as the DTN2 daemon, which may be misleading if you have multiple installations. After standard installation of both DN2 and ION I had two different dtnd daemons in two different directories (/etc/bin and /etc/usr/bin if I am not wrong), both of them in the default path. I thought to switch on DTN2 and in fact I was switching on the IBR-DTN one. Pheraps, it would have been preferable to use a different name, such as ibrdtnd, but the important thing is to know that you can face this trivial but tricky problem if you have both DTN2 and IBR-DTN installed on the same machine. With ION the problem is less evident but also more dangerous. IBR DTN daemon is incompatible (if on) with that of ION, as expected. Unfortunately, this incomaptibility is not as evident as with DTN2. Everything seems OK but in fact it is not. Thus you must be sure that the IBR-DTN daemon is off before launching ION. Here the most critical point is that (IBR) dtnd is switched on by default at boot, so you can have it always on without being aware of this (as it happened to me) just because you have installed the Debian IBR-DTN package. I was wondering if it would not be safer to remove the call of the IBR dtnd from the boot in the default installation to solve the problem by root in next releases. By the way, I like the possibility to have everything correctly installed with apt-get install. Thanks for this! Yours, Carlo
________________________________________ Da: Ibr-dtn [ibr-dtn-bounces@ibr.cs.tu-bs.de] per conto di Sebastian Schildt [schildt@ibr.cs.tu-bs.de] Inviato: venerdì 11 settembre 2015 21.20 A: ibr-dtn; Maël Auzias Oggetto: Re: [ibr-dtn] Double usage of routing protocol
Hi,
exactly, you can run two (or more) local IBR-DTN daemons if they are using different ports for API and TCP-CL and different discovery addresses. Between the different overlays you can only transmit data statically, i.e. on a node with two DTN daemons running under different ports, you can add one as static neighbour to the other and use some static routes to „lift“ bundles from one overlay to the next. Probably there are a million pitfalls doing this, but it could work :) I used something similar (two daemons on one node) when I wanted to interconnect a IEEE 802.15.4 DTN (no flooding, no discovery) with a noisy IP-based DTN (many nodes, Prophet, lots of traffic), to avoid DoSing the 802.15.4 network.
Sebastian
On 10 Sep 2015, at 07:21, Maël Auzias ibrdtn@auzias.net wrote:
Hello Sebastian,
thanks for your answer. I'm just wondering: If I "make sure there is no auto discovery between the two" how does my first node will forward the bundle to the other close by node on the different overlay if they don't discover each other?
By reading your answer I thought about running two local IBR-DTN daemon (is it at least possible?) and each of them process a different algorithm. Not the most efficient way, but on the idea it „should work“(tm).
Anyway, thanks again !
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774
On Wed, Sep 9, 2015 at 9:22 PM, Sebastian Schildt schildt@ibr.cs.tu-bs.de wrote: Hello Maël
Not sure what MEB is, but currently IBR-DTN does not support configuring different routing protocols at once with one exception: I think even with Prophet or Epidemic enabled, static routes are honoured. So in a hacky way, this could be used to forward bundles to another statically configured neighbour, that runs another routing protocol (possible on different TCPCL ports and Discovery addresses), so basically you build n separate DTN networks/overlays , with each one using a different routing, and make sure there is no auto discovery between the two, and use static routing to transfer bundles between the two overlays. Not too flexible, and more complexity, but it „should work“(tm).
Sebastian
On 07 Sep 2015, at 14:55, Maël Auzias ibrdtn@auzias.net wrote:
Hi dear list!
I was wondering if it is possible to use two different routing protocol among a network.
The easiest one I can think, and fastest to deploy, of is:
- One dynamic routing protocol (BATMAN, spray-and-wait, prophet...)
- One static routing protocol based on destination, i.e., all bundles with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! 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.
-- !! 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 Carlo,
Thanks for your mail, I guess this spared me some debugging time... You did not mention running two IBR-DTN daemons on the same node. Did you tried this? What were the fallback? I think my problem can be solved just by using static routes that seems, by far, the simplest solution.
Have a nice day, and thanks again!
Best regards, --- Auzias Maël auzias.net https://www.auzias.net/en/ - vcard https://www.auzias.net/auzias.vcf - thesis http://people.irisa.fr/Mael.Auzias/ *GSM: 0033 695 118 774*
On Fri, Sep 11, 2015 at 11:36 PM, Carlo Caini carlo.caini@unibo.it wrote:
Dear Sebastian, Concerning multiple DTN daemons, it may be of some interest to share my little experience with multiple daemons of different DTN implementations with IBR DTN users and maintainers. You can install both ION and DTN2 on the same machine, but if you switch on both, you have problems. This means that you have to duble check that the other daemon is off before switching on the wanted one. The same is basically true also for IBR-DTN and the others two. With IBR-DTN and DTN2 the problem is worsened by the fact that the IBR daemon is named "dtnd" exactly as the DTN2 daemon, which may be misleading if you have multiple installations. After standard installation of both DN2 and ION I had two different dtnd daemons in two different directories (/etc/bin and /etc/usr/bin if I am not wrong), both of them in the default path. I thought to switch on DTN2 and in fact I was switching on the IBR-DTN one. Pheraps, it would have been preferable to use a different name, such as ibrdtnd, but the important thing is to know that you can face this trivial but tricky problem if you have both DTN2 and IBR-DTN installed on the same machine. With ION the problem is less evident but also more dangerous. IBR DTN daemon is incompatible (if on) with that of ION, as expected. Unfortunately, this incomaptibility is not as evident as with DTN2. Everything seems OK but in fact it is not. Thus you must be sure that the IBR-DTN daemon is off before launching ION. Here the most critical point is that (IBR) dtnd is switched on by default at boot, so you can have it always on without being aware of this (as it happened to me) just because you have installed the Debian IBR-DTN package. I was wondering if it would not be safer to remove the call of the IBR dtnd from the boot in the default installation to solve the problem by root in next releases. By the way, I like the possibility to have everything correctly installed with apt-get install. Thanks for this! Yours, Carlo
Da: Ibr-dtn [ibr-dtn-bounces@ibr.cs.tu-bs.de] per conto di Sebastian Schildt [schildt@ibr.cs.tu-bs.de] Inviato: venerdì 11 settembre 2015 21.20 A: ibr-dtn; Maël Auzias Oggetto: Re: [ibr-dtn] Double usage of routing protocol
Hi,
exactly, you can run two (or more) local IBR-DTN daemons if they are using different ports for API and TCP-CL and different discovery addresses. Between the different overlays you can only transmit data statically, i.e. on a node with two DTN daemons running under different ports, you can add one as static neighbour to the other and use some static routes to „lift“ bundles from one overlay to the next. Probably there are a million pitfalls doing this, but it could work :) I used something similar (two daemons on one node) when I wanted to interconnect a IEEE 802.15.4 DTN (no flooding, no discovery) with a noisy IP-based DTN (many nodes, Prophet, lots of traffic), to avoid DoSing the 802.15.4 network.
Sebastian
On 10 Sep 2015, at 07:21, Maël Auzias ibrdtn@auzias.net wrote:
Hello Sebastian,
thanks for your answer. I'm just wondering: If I "make sure there is no auto discovery between the two" how does my
first node will forward the bundle to the other close by node on the different overlay if they don't discover each other?
By reading your answer I thought about running two local IBR-DTN daemon
(is it at least possible?) and each of them process a different algorithm. Not the most efficient way, but on the idea it „should work“(tm).
Anyway, thanks again !
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774
On Wed, Sep 9, 2015 at 9:22 PM, Sebastian Schildt <
schildt@ibr.cs.tu-bs.de> wrote:
Hello Maël
Not sure what MEB is, but currently IBR-DTN does not support configuring
different routing protocols at once with one exception: I think even with Prophet or Epidemic enabled, static routes are honoured. So in a hacky way, this could be used to forward bundles to another statically configured neighbour, that runs another routing protocol (possible on different TCPCL ports and Discovery addresses), so basically you build n separate DTN networks/overlays , with each one using a different routing, and make sure there is no auto discovery between the two, and use static routing to transfer bundles between the two overlays. Not too flexible, and more complexity, but it „should work“(tm).
Sebastian
On 07 Sep 2015, at 14:55, Maël Auzias ibrdtn@auzias.net wrote:
Hi dear list!
I was wondering if it is possible to use two different routing
protocol among a network.
The easiest one I can think, and fastest to deploy, of is:
- One dynamic routing protocol (BATMAN, spray-and-wait, prophet...)
- One static routing protocol based on destination, i.e., all bundles
with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on
how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards,
Auzias Maël auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! 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.
-- !! 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.
Dear Auzias, Unfortunately, I have not any experience on running multiple IBR DTN daemons, so I cannot be on any help to you, sorry. My mail was somewhat complementary to the answer given by Sebastian. Yours, Carlo
________________________________________ Da: auzias.mael@gmail.com [auzias.mael@gmail.com] per conto di Maël Auzias [ibrdtn@auzias.net] Inviato: lunedì 14 settembre 2015 8.32 A: Carlo Caini; ibr-dtn@ibr.cs.tu-bs.de Oggetto: Re: [ibr-dtn] Double usage of routing protocol
Hello Carlo,
Thanks for your mail, I guess this spared me some debugging time... You did not mention running two IBR-DTN daemons on the same node. Did you tried this? What were the fallback? I think my problem can be solved just by using static routes that seems, by far, the simplest solution.
Have a nice day, and thanks again!
Best regards, --- Auzias Maël auzias.nethttps://www.auzias.net/en/ - vcardhttps://www.auzias.net/auzias.vcf - thesishttp://people.irisa.fr/Mael.Auzias/ GSM: 0033 695 118 774
On Fri, Sep 11, 2015 at 11:36 PM, Carlo Caini <carlo.caini@unibo.itmailto:carlo.caini@unibo.it> wrote: Dear Sebastian, Concerning multiple DTN daemons, it may be of some interest to share my little experience with multiple daemons of different DTN implementations with IBR DTN users and maintainers. You can install both ION and DTN2 on the same machine, but if you switch on both, you have problems. This means that you have to duble check that the other daemon is off before switching on the wanted one. The same is basically true also for IBR-DTN and the others two. With IBR-DTN and DTN2 the problem is worsened by the fact that the IBR daemon is named "dtnd" exactly as the DTN2 daemon, which may be misleading if you have multiple installations. After standard installation of both DN2 and ION I had two different dtnd daemons in two different directories (/etc/bin and /etc/usr/bin if I am not wrong), both of them in the default path. I thought to switch on DTN2 and in fact I was switching on the IBR-DTN one. Pheraps, it would have been preferable to use a different name, such as ibrdtnd, but the important thing is to know that you can face this trivial but tricky problem if you have both DTN2 and IBR-DTN installed on the same machine. With ION the problem is less evident but also more dangerous. IBR DTN daemon is incompatible (if on) with that of ION, as expected. Unfortunately, this incomaptibility is not as evident as with DTN2. Everything seems OK but in fact it is not. Thus you must be sure that the IBR-DTN daemon is off before launching ION. Here the most critical point is that (IBR) dtnd is switched on by default at boot, so you can have it always on without being aware of this (as it happened to me) just because you have installed the Debian IBR-DTN package. I was wondering if it would not be safer to remove the call of the IBR dtnd from the boot in the default installation to solve the problem by root in next releases. By the way, I like the possibility to have everything correctly installed with apt-get install. Thanks for this! Yours, Carlo
________________________________________ Da: Ibr-dtn [ibr-dtn-bounces@ibr.cs.tu-bs.demailto:ibr-dtn-bounces@ibr.cs.tu-bs.de] per conto di Sebastian Schildt [schildt@ibr.cs.tu-bs.demailto:schildt@ibr.cs.tu-bs.de] Inviato: venerdì 11 settembre 2015 21.20 A: ibr-dtn; Maël Auzias Oggetto: Re: [ibr-dtn] Double usage of routing protocol
Hi,
exactly, you can run two (or more) local IBR-DTN daemons if they are using different ports for API and TCP-CL and different discovery addresses. Between the different overlays you can only transmit data statically, i.e. on a node with two DTN daemons running under different ports, you can add one as static neighbour to the other and use some static routes to „lift“ bundles from one overlay to the next. Probably there are a million pitfalls doing this, but it could work :) I used something similar (two daemons on one node) when I wanted to interconnect a IEEE 802.15.4 DTN (no flooding, no discovery) with a noisy IP-based DTN (many nodes, Prophet, lots of traffic), to avoid DoSing the 802.15.4 network.
Sebastian
On 10 Sep 2015, at 07:21, Maël Auzias <ibrdtn@auzias.netmailto:ibrdtn@auzias.net> wrote:
Hello Sebastian,
thanks for your answer. I'm just wondering: If I "make sure there is no auto discovery between the two" how does my first node will forward the bundle to the other close by node on the different overlay if they don't discover each other?
By reading your answer I thought about running two local IBR-DTN daemon (is it at least possible?) and each of them process a different algorithm. Not the most efficient way, but on the idea it „should work“(tm).
Anyway, thanks again !
Best regards,
Auzias Maël auzias.nethttp://auzias.net - vcard - thesis GSM: 0033 695 118 774
On Wed, Sep 9, 2015 at 9:22 PM, Sebastian Schildt <schildt@ibr.cs.tu-bs.demailto:schildt@ibr.cs.tu-bs.de> wrote: Hello Maël
Not sure what MEB is, but currently IBR-DTN does not support configuring different routing protocols at once with one exception: I think even with Prophet or Epidemic enabled, static routes are honoured. So in a hacky way, this could be used to forward bundles to another statically configured neighbour, that runs another routing protocol (possible on different TCPCL ports and Discovery addresses), so basically you build n separate DTN networks/overlays , with each one using a different routing, and make sure there is no auto discovery between the two, and use static routing to transfer bundles between the two overlays. Not too flexible, and more complexity, but it „should work“(tm).
Sebastian
On 07 Sep 2015, at 14:55, Maël Auzias <ibrdtn@auzias.netmailto:ibrdtn@auzias.net> wrote:
Hi dear list!
I was wondering if it is possible to use two different routing protocol among a network.
The easiest one I can think, and fastest to deploy, of is:
- One dynamic routing protocol (BATMAN, spray-and-wait, prophet...)
- One static routing protocol based on destination, i.e., all bundles with dtn://all/* as destination are forwarded to all nodes (and thus we deploy an epidemic routing protocol for a specific type of messages).
Did anyone work on such a case? Do you have any idea or suggestion on how to do that? Is using the MEB a way to achieve this? Isn't MEB too much (or not enough) for this?
Have a nice day, and thanks for further response (if any).
Best regards,
Auzias Maël auzias.nethttp://auzias.net - vcard - thesis GSM: 0033 695 118 774 -- !! 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.demailto:ibr-dtn-request@ibr.cs.tu-bs.de> !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
-- !! 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.demailto:ibr-dtn-request@ibr.cs.tu-bs.de> !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
participants (3)
-
Carlo Caini -
Maël Auzias -
Sebastian Schildt