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?
2. Will the Sun Ray be able to negotiate a lower MTU size if there is a
MTU size problem on the connection?
3. Why take this longer route if the Server can read the file directly
from disk?
But maybe I did not quite understand how the .parms systems works.
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
