Ok, lets go for the .parms files.
Ivar
Bob Doolittle wrote:
Ivar Janmaat wrote:
Hello Bob,
Bob Doolittle wrote:
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.
So this is not the normal max MTU discover procedure. It is a Sun Ray
specific procedure.
Must this value be sent by the DTU or can this value also be sent in
some other way?
Currently, it has to be sent by the DTU. The idea
is that most commonly traffic paths are
symmetrical so you really do want the same max MTU
in both directions, and since most typically it's the
last hop to the Sun Ray that has the most restrictive MTU
it makes sense to pick up the DHCP configuration
there and carry it through the system.
Let's not go through the "efficiency vs
correctness" discussion again, I suspect we could
agree that ideally you want the same MTU in both
directions for most routing topologies, then you
get efficient *and* correct behavior in both
directions.
3. Why take this longer route if the Server can read the file
directly from disk?
Considering your new insight. I guess question 3 becomes relevant again.
Why not use another way of getting this info to the SRSS service?
Basically because we could invent something new to
configure the server sends relatively easily, but
we still have to extend it to the client sends
somehow for the general case. And we already have
a mechanism that does this properly starting with
a DHCP configuration parameter.
Given that observation, it seems simplest to
extend the .parms file so the client can learn the
max MTU size and use the existing mechanism to
reflect that to the server.
"overhaul" is a relative term. I haven't sized the effort.
As Mike mentioned, you can't reliably "discover" a
max MTU size...
It would be sufficient if the endpoint of the VPN tunnel would
communicate the MAX MTU correctly.
The tunnel will handle fragmentation over the Internet from vpn to
vpn router.
In this specific case, yes. After discussing this
with Otto, we're inclined to attack the more
general case, since the proposed approach seems to
be simple, rather than design a new mechanism that
only solves a part of the problem. Otto is more
familiar with the firmware networking code and
seems to feel it's not such an "overhaul" after all.
-Bob
_______________________________________________
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
