Hello Bob,
I see your problem.
I have added some in line comments.
Bob Doolittle wrote:
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 difference between the server and the Sun ray is that the server
reassembles fragments and the Sun Ray drops fragments.
At least that is my understanding.
So communication from the client to the server will not fail when max
MTU is exceeded because the server will reassemble. It will only be less
than optimal.
With USB devices this might be a problem but for requesting info from
the server I don't think it will be a problem.
If the communication from the server to the client gets fragmented the
Sun Ray drops the fragments and communication will fail badly.
So it is essential that the server stays within the "max MTU" size while
sending the .parms file.
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.
I don't understand what you are saying about ifconfig.
As I mentioned above I do agree that the Server should always honor a
max MTU.
Greg Bender told me that lowering MTU size on the server interface will
not help.
I will only make things worse since packets will be fragmented form the
start and discarded by the Sun Ray.
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.
This was my point. The server needs to honor a max MTU and know what the
max MTU is.
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.
Correct.
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.
With USB key uploads it would also be more efficient to have max server
side MTU in place.
This will reduce load on the server since reassembling fragments is not
needed anymore.
But this is less important for me at this time.
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).
Ok, this seems to be a correct way of doing it.
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.
I did not thought about that.
Now I understand why it is only possible to use DHCP or Tadpole style
MTU settings at this moment.
Wouldn't it be possible to fake max MTU discovery on the server so it
will be lower regardless of the MTU size of the Sun Ray?
I need a solution quickly. I don't think I can wait for a mayor overhaul
if it will take months.
Kind regards,
Ivar
-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
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
