From: wu xiaofei <lampsu@gmail.com>
To: Mark Smith <lk-netdev@lk-netdev.nosense.org>
Cc: netdev@vger.kernel.org
Subject: Re: about packets forwarding
Date: Wed, 2 Sep 2009 20:31:41 +0800 [thread overview]
Message-ID: <f4f837ab0909020531l46c001d2o8fa08f63f9525332@mail.gmail.com> (raw)
In-Reply-To: <20090902201800.1dbb4988.lk-netdev@lk-netdev.nosense.org>
2009/9/2 Mark Smith <lk-netdev@lk-netdev.nosense.org>:
> On Wed, 2 Sep 2009 17:03:42 +0800
> wu xiaofei <lampsu@gmail.com> wrote:
>
>> Hello,
>>
>> I have something to ask here.
>>
>> The topology of the network is as follows.
>> There are six Nodes (A, B, C, D, M, N).
>>
>> M
>> |
>> A
>> / \
>> B D
>> \ /
>> C
>> |
>> N
>>
>> M-A, C-N are wired links.
>> A-B, B-C, A-D, D-C are wireless links.
>>
>> Node M wnats to communicate with node N. Because the wireless links
>> are not very reliable, I want to forward the packets through A-B-C and
>> A-D-C simultaneously (When Node A receives packets(from Node M) from
>> its wired interface eth0, It will forward the same packets to its
>> wireless interfaces wlan0 and wlan1 simultaneously) . How to implement
>> this?
>>
>
> Packets being duplicated in this manner is generally considered an
> error - protocols are designed to deal with it, but only as an error
> robustness mechanism. In other words, it won't break anything, but
> performance is very likely to suffer.
>
I will process the duplicated packets on node C, just forward one copy
to node N.
My purpose:
to improve the reliablity of the wireless links, make our individual
network more robust.
If the path A-B-C is not available, maybe the path A-D-C is still
available, so the communication between node M and node N will not be
interrupted.
The probability of the path A-B-C and A-D-C broken at the same time is small.
> The Internet protocols are designed on the assumption of a low
> possibility of packet loss (1 in 100)- they only assume each
> link in the path will have an error detection mechanism (and drop them
> when errors occur), but not an error correction mechanism. If the
> possibility of packet loss is high (1 in 10), then it is expected that
> the link layer itself will implement error detection and recovery.
>
We use 802.11b/g wireless cards on our nodes.
The wireless links may have varying quality in terms of packet loss,
data rates, and interference. It's not very stable. It's very
different from wired links.
--
Wu
next prev parent reply other threads:[~2009-09-02 12:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f4f837ab0907220706g1129a1cbv7dfad944e5bada16@mail.gmail.com>
[not found] ` <f4f837ab0909020127o3359ed03j224ef51a0673bcd9@mail.gmail.com>
2009-09-02 9:03 ` about packets forwarding wu xiaofei
2009-09-02 10:48 ` Mark Smith
2009-09-02 12:31 ` wu xiaofei [this message]
2009-09-02 13:14 ` Xiaofei Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4f837ab0909020531l46c001d2o8fa08f63f9525332@mail.gmail.com \
--to=lampsu@gmail.com \
--cc=lk-netdev@lk-netdev.nosense.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox