Ivar Janmaat wrote:
Hello Bob,
Ok, I mentioned auth.props as an example.
*.parms file is fine with me, if you can make it work.
I only found it a bit complicated to put MTU size in a .parms.
As I understand it the systems works as follows:
1. The Sunray contacts the Server and reads the .parms file.
2. It than has to negotiate the MTU size with the Server.
3. The server lowers the MTU size.
Questions:
1. Will the Sun Ray be able to read the .parms file if there is a MTU
size problem on the connection?
It's the sender's responsibility to restrict
packet sizes to a "max MTU". In this transaction,
the Sun Ray is only sending TFTP requests. It's
the server that is sending the actual file, so
it's the server that needs to stay within a "max
MTU", not the client. So this should be fine from
the client perspective.
The server needs to honor a max
MTU if you expect it to interoperate with a Sun
Ray properly in any case, since the rendering packets
are also UDP and will frequently be max-sized. You
can configure one via ifconfig and I believe it also
tries to do max MTU discovery.
2. Will the Sun Ray be able to negotiate a lower MTU size if there is
a MTU size problem on the connection?
I'm not sure what you mean here. What
"connection"? The TFTP negotiation is not
connection-oriented, it uses UDP. If you mean
restricted MTU somewhere on the path between
client and server, I addressed that in my previous
answer. If the server doesn't honor a max MTU
when sending the .parms file, and if the .parms
file becomes larger than the max MTU, there could
be a problem. That's true for any server-side
configuration and is unrelated to configuring the
client for a max MTU. It's solved by configuring
the server properly.
3. Why take this longer route if the Server can read the file directly
from disk?
It's an RFE for client-side configuration of max MTU that
we are discussing. Somehow this info has to get
to the client. If it's going to driven by some
configuration info on the server, somehow the
server has to read that info from disk and send it
to the client.
But maybe I did not quite understand how the .parms systems works.
The client simply issues a TFTP request for the
server to send it the contents of the .parms file.
That file contains a number of key=value client
configuration parameters. The proposal is that we
simply add a new key to represent the max MTU size
the client should use when sending packets. I
don't see how this is any less efficient than any
other configuration mechanism one could propose
(other than DHCP, that is).
The tricky part of implementing this is that,
today, once the firmware has booted up the max MTU
is fixed. So doing it after the DHCP negotiation
is problematic and needs an overhaul. That would
be true for any form of non-DHCP server-side
configuration of max MTU.
-Bob
Kind regards,
Ivar
Bob Doolittle wrote:
Ivar Janmaat wrote:
Why is option 1, setting "Max MTU size" as a variable in a config
file (maybe not auth.props), not an option which can be done quickly?
Normally this would only means adding a couple of code lines to the
program which sets the MTU size.
Something which could be done in a day or so.
I suspect Mike's objection was to the use of auth.props. We already
have a file
to configure network/boot parameters - the *.parms files, so we
wouldn't want
to start randomly scattering this configuration information around.
So, as long as you're OK with "not auth.props", then #2 seems to be
exactly
what you are asking for. You'd be able to set Max MTU size in a
config file,
specifically the *.parms config file.
I agree that this seems most in line with our current architecture
and should not
be difficult to implement in a patch.
-Bob
Kind regards,
Ivar
ottomeister wrote:
On 9/7/06, Ivar Janmaat <[EMAIL PROTECTED]> wrote:
1. Sun can adds a "Max MTU size" option to auth.props
2. Sun fixes RFE/bug 6457500 so we can use *.parms files to set
Max MTU
size.
3. Sun makes new firmware with which we can set the MTU size
options on
the Sun Ray manually.
4. Sun develops something called MTU discovery between Sun Ray Server
and Sun Ray
We would prefer options 1 or 2 since this is probably fastest to
implement and will be sufficient for our needs.
For the future we think option 4 will be great.
Option 3 we don't like since we want the Sun Ray as stateless as
possible.
The important questions is: Which one can be done quickly?
Number 2 is probably the option that could be delivered the earliest.
Number 3 will probably happen but it's very unlikely that a change
that large would be considered for inclusion in a patch. It would
have
to wait for a full release.
Number 4 might happen but there are many networks where PMTU
discovery does not work, usually because of ICMP messages not
being generated or being blocked or dropped or otherwise lost in the
network.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
