Ivar Janmaat wrote:
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.
Correct.
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.
Correct.
With USB devices this might be a problem but for requesting info from
the server I don't think it will be a problem.
I assume you mean "sending packets to" rather than "requesting info
from". There are all
sorts of upstream traffic, but other than upstream video, audio, and
bulk USB data the
packet size is small.
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.
Correct although typically .parms files are quite small
and unlikely to exceed max MTU.
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.
This was a mistake on my part, sorry. I just re-read some of the
SRSS source, and now I recollect that the client's "max MTU"
is transmitted in the initial TCP connection to the server and
passed through SRSS to the services (e.g. X server) so that they
will also honor that value on transmission. So the value set in
the client affects traffic in both directions.
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.
What do you mean by "USB key uploads"?
Server side MTU affects downstream traffic, client side MTU
affects upstream...
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.
"overhaul" is a relative term. I haven't sized the effort.
As Mike mentioned, you can't reliably "discover" a
max MTU size...
-Bob
These opinions are my own, not my employer's.
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
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
