[<prev] [next>] [day] [month] [year] [list]
Message-Id: <9A4B18C9-91B4-4B9B-A147-49C3BB04E296@cs.uni-bonn.de>
Date: Mon, 13 Jul 2009 08:24:36 +0200
From: Tim Schneider <schneid5@...uni-bonn.de>
To: netdev <netdev@...r.kernel.org>
Subject: Re: Using Wireless Extensions in a Kernel Module
Hi Glen, hi Marcel
thank you for your answers.
I am trying to develop the algorithm for a wireless multihop network,
so no, I'm not making the classical error ;) Still you're right that I
should consider the possibility, that the Algorithm is used on a wired
network. In that case it definitely should not crash the whole system.
Thank you for your hint with the other mailing list. I'm going to try
my luck there.
Regards
Tim
Am 11.07.2009 um 10:44 schrieb Glen Turner:
>
> Hi Tim,
>
> I'm not sure you aren't making a classic error of optimising the
> unusual
> case.
>
> The usual situation is that the TCP sender is on the wired network,
> the
> TCP receiver is on the wireless network. Since the sender determines
> the
> packet scheduling, determining the received signal strength at the TCP
> receiver isn't much help.
>
> What would be really, really useful is a channel to get this sort of
> information back to the sender in a form in which the feedback is
> useful
> even after a RTT/2 delay. There are a few explicit congestion
> notification
> protocols around, and adapting one of those to add the wireless
> condition
> of intermediate and end hops could be the sort of useful
> augmentation that
> gives these protocols enough of an advantage of TCP to be worth
> deploying.
>
> Best wishes, Glen
>
> --
> Glen Turner <http://www.gdt.id.au/~gdt/>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists