Packet analysis: WinXP vs. Linux<->VMS shows dramatic differences

[John E. Malmberg]

In article <CF0913E9C3D53D4E94DE47FDE25C633D05048E8E at hermes.cofiroute.com>, COLLOT Jean-Yves <jean-yves.collot at cofiroute.fr> writes:
>
> Once again, I am sorry, but it looks like I don't understand.
>
> As far as I know, Ben pointed out a problem of performances when writing
> files on a Samba/VMS 2.2.8 server from an XP client. I could reproduce that
> problem by using "ruby", but I could not by using anything else. Another way
> to say is: according to me, the "WinXP vs. Linux<->VMS shows dramatic
> differences" topic is true only when using "ruby". Could someone tell me if
> I am right or wrong here?

On SAMBA 2.0.6 VMS and Microsoft Windows NT 4.0 client several years ago,
I could reproduce the same problem by just copying a large file back and
forth.  I used the NETSCAPE browser image for Alpha as a test case.  At the
time I was not trying to debug performance issues, but I did notice that
the file was sent with sections out of order.

When I went from VMS SAMBA to VMS SAMBA, all sections of the file were sent
in the same order.

What Ben has determined is that there is a difference in the protocol
negotiation between SAMBA to SAMBA and Microsoft Windows to SAMBA 2.2.8.
And that Microsoft Windows to SAMBA 3.0.7 is able to better negotiate the
protocol.

Now why SAMBA 2.2.8 on VMS is not negotiating that protocol is the unknown.

As I see no VMS specific code in the sections that negotiate the protocol,
I would tend to think that the answer may be in a later SAMBA release, unless
there is some unknown item that is not set correctly.

One test would be to try SAMBA 2.2.8 on a LINUX server and see if the same
protocols are negoticated between it and the Microsoft Windows client as
with SAMBA 2.2.8 on OpenVMS.

If the behavior is the same on LINUX SAMBA 2.2.8 and OpenVMS, then it is
likely that it will take a newer version of SAMBA to fix.  If the behavior
is different, then it may be able to find what needs to be changed on the
OpenVMS system.

Comparing the traces of the protocol negotiation with the source code of
what protocols are known is another way of looking at the problem.

> When you refer to "a Windows NT 4.0 client on SAMBA 2.0.6", or to issues
> dealing with "modify in place stream-CRLF or stream-LF files", you are
> perfectly right, but I don't clearly see the connection with Ben's problem.

Small connection.  Ben's problem points out an issue that greatly increases
the complexity of solving the conversion of stream files to VFC files.  A VFC
file is larger than a stream file, so it is not easy to convert it out of
order.  All solutions I can think of have a performance penalty, some worse
than others.  But that is a different problem.

> Porting Samba 3 or 4 to VMS is obviously a very nice thing to do, but I fear
> that it will take a lot of work and quite some time. In the meantime, I may
> be able to understand or even fix Ben's problem on 2.2.8, so I prefer to
> focus on that specific problem.

The main advantage by working on the SAMBA3/4 port now is that it is possible
to get changes put in the UNIX code that can help the VMS port, but it usually
is needed to demonstrate a UNIX advantage to doing so.

Once I understand all the work that you have done on 2.2.8, I do not think
it will be too hard for me to get either 2.2.11. or 3.0.x running.

Time however is an issue.  And more volunteers that can handle implementing
and testing specific issues can speed things up.

> I have a last question: what is exactly "the notepad problem on VMS" ?

The "notepad problem" is not a VMS specific SAMBA issue, it is an issue on
the UNIX SAMBA systems.

It is because UNIX SAMBA serves LINUX text files as stream-LF, and Notepad
wants STREAM-CRLF.

Using WORDPAD or several other editors on Microsoft Windows does not show
the problem, as they will auto-detect if the file is stream-LF or stream-CRLF.
Most of Microsoft Windows will also handle both formats.  Just like the
CRTL will convert the VMS text formats to a simulated stream-LF.

As it is popular to use NOTEPAD to edit text files, when those files are
modified or created by the LINUX system there is a noticable problem.

The part of serving the text files as STREAM-CRLF to Microsoft Windows for
read only from SAMBA-VMS is easy to solve.  It is the write back that is
harder.  If the writen blocks were always in order, than it would not be
much of a problem to convert on the fly.

With the written blocks out of order, the insertion of the out-of-order blocks
will result in having to move some of the earlier written blocks to make room,
something that is not good.  Tempfiles can not be used as the server does not
know if this is a file transfer, or an application doing random read/write
access to a file.

Now the last time I did any research on this was at least three years ago, so
I may be a little fuzzy on the details.

-John
wb8tyw at qsl.net
Personal Opinion Only