From: Ian Kent <raven@themaw.net>
To: David Meleedy <david.meleedy@analog.com>
Cc: autofs@linux.kernel.org
Subject: Re: /net support
Date: Wed, 01 Nov 2006 10:39:39 +0800 [thread overview]
Message-ID: <1162348779.3579.19.camel@localhost> (raw)
In-Reply-To: <200610312042.k9VKgBVw009630@jetcar.spd.analog.com>
On Tue, 2006-10-31 at 15:42 -0500, David Meleedy wrote:
> > That very much depends on usage.
> >
> > If you have a bunch of clients that typically open and load files of
> > potentially several hundred megabytes then UDP retransmits can become a
> > problem.
> >
> > But then if traffic is light there's not much to be gained and if there
> > are traffic spikes possibly something to be lost.
>
> Well, our CAD software can generate files varying from several hundred
> megabytes up to 1-3 gigabytes. So yes, we actually do have
> large files being transmitted, which is why I had been looking at not
> using tcp on the LAN. But tcp is the only reliable WAN method I've
> found. I think what I'm going to have to do is generate local NIS
> maps for every client and use a "program" script to read them. That
> way I can insert the appropriate flags in there, depending on whether
> or not a machine is on the LAN vs. WAN. I had just noticed that on
> Solaris, the behavior seems to work much better than on linux, so I was
> kind of wondering how they had solved it.
That's a good point actually.
Solaris uses a proximity metric which I've attempted to put into v5.
In particular it discriminates between local network, local subnet and
other network. This happens before ping tests are done. So we do know if
we are requesting a mount on a network not directly accessible though a
local interface. Of course that network may not actually be over a WAN
such as for sites with many local subnets.
I'm not sure yet about the implications or how much effort it would be
needed to insist that the TCP protocol always and only be used for mount
requests whose proximity is other network. The proximity check is
granular in that it is written to be passed the protocols to be checked.
At the moment it always checks both. I expect I would need to also grab
the routing information and examine the hop count for this to work in a
reasonable way.
I'll have a poke around and see what's involved.
Ian
next prev parent reply other threads:[~2006-11-01 2:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-27 20:22 /net support David Meleedy
2006-10-27 23:04 ` Jeff Moyer
2006-10-28 4:05 ` Ian Kent
2006-10-30 22:52 ` David Meleedy
2006-10-30 23:29 ` Jeff Moyer
2006-10-31 0:14 ` David Meleedy
2006-10-31 8:31 ` Ian Kent
2006-10-31 15:04 ` Jeff Moyer
2006-10-31 20:42 ` David Meleedy
2006-10-31 21:00 ` Joseph V Moss
2006-10-31 21:58 ` David Meleedy
2006-11-01 2:39 ` Ian Kent [this message]
2006-11-01 20:32 ` David Meleedy
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=1162348779.3579.19.camel@localhost \
--to=raven@themaw.net \
--cc=autofs@linux.kernel.org \
--cc=david.meleedy@analog.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.