Re: non-blocking connect

Re: non-blocking connect

[Richard Stallman]

I see in that message two versions of a certain file, one good, one
corrupted.  (I forwarded the message here.)  How often does this
corruption occur?  Is it always at the same place, always identical?
If not, what varies?

Re: non-blocking connect

[Jochem Kossen]

On Thu, Nov 04, 2004 at 04:51:34AM -0500, Richard Stallman wrote:
> I see in that message two versions of a certain file, one good, one
> corrupted.  (I forwarded the message here.)  How often does this
> corruption occur?  Is it always at the same place, always identical?

It seems to corrupt the files around 3 of 10 times. It's not always at
the same place, and also not identical. So to sum up, everything is
pretty much random.

Now, i've set tramp-chunksize to 500 and 1024, and i can't seem to get
the corruption anymore :-S I'm now gradually trying higher values
(2048 atm). But i'm just trying this for about an hour, so don't
consider it a conclusion.

> If not, what varies?

The place of corruption in the file, and the 'characters'/binary data
it inserts.

So, the things i suspect might have something to do with it:
 - chunksize (what does the default do in comparison with values like
   500/1024/2048)? I read the documentation, but it doesn't mention
   what tramp does if it's set to nil.
 - traffic goes through an OpenBSD 3.6 firewall with scrubbing
   (traffic normalization) on

BTW, the remote/target host is running FreeBSD 5.2.1-RELEASE

Regards,

Jochem

Re: non-blocking connect

[Kai Grossjohann]

Jochem Kossen <jkossen@xs4all.nl> writes:

> So, the things i suspect might have something to do with it:
>  - chunksize (what does the default do in comparison with values like
>    500/1024/2048)? I read the documentation, but it doesn't mention
>    what tramp does if it's set to nil.

Setting tramp-chunksize to 500 means that Tramp will send 500 bytes of
data, then wait a bit before sending the next chunk of data.

Setting tramp-chunksize to nil means that Tramp will send all of the
data at once, unchunked, so to speak.  (For instance, for writing a
file via base64 inline encoding, Tramp would base64-encode the buffer
contents, then send the whole encoded buffer to the remote end at once
with a single process-send-region invocation.)

Kai

Re: non-blocking connect

[Stefan]

>> I see in that message two versions of a certain file, one good, one
>> corrupted.  (I forwarded the message here.)  How often does this
>> corruption occur?  Is it always at the same place, always identical?

> It seems to corrupt the files around 3 of 10 times. It's not always at
> the same place, and also not identical. So to sum up, everything is
> pretty much random.

What kind of corruption is it?
Could it just be due to the problem of SSH dropping some (multiple of
1024) bytes that we sometimes see in cunjunction with CVS?


        Stefan

Re: non-blocking connect

[Kai Grossjohann]

Stefan <monnier@iro.umontreal.ca> writes:

> What kind of corruption is it?
> Could it just be due to the problem of SSH dropping some (multiple of
> 1024) bytes that we sometimes see in cunjunction with CVS?

The documentation for the variable tramp-chunksize shows a method for
finding out if the bug is present in Emacs.  It seems to occur with
any program, not just wc and ssh.

Kai

Re: non-blocking connect

[Stefan Monnier]

>> What kind of corruption is it?
>> Could it just be due to the problem of SSH dropping some (multiple of
>> 1024) bytes that we sometimes see in cunjunction with CVS?

> The documentation for the variable tramp-chunksize shows a method for
> finding out if the bug is present in Emacs.  It seems to occur with
> any program, not just wc and ssh.

Hmmm... so would it be a bug in Emacs?


        Stefan

Re: non-blocking connect

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> What kind of corruption is it?
>>> Could it just be due to the problem of SSH dropping some (multiple of
>>> 1024) bytes that we sometimes see in cunjunction with CVS?
>
>> The documentation for the variable tramp-chunksize shows a method for
>> finding out if the bug is present in Emacs.  It seems to occur with
>> any program, not just wc and ssh.
>
> Hmmm... so would it be a bug in Emacs?

Difficult to say: it seems to depend on a libc/Emacs interaction.

Kai

Re: non-blocking connect

[Stefan]

> Difficult to say: it seems to depend on a libc/Emacs interaction.

Do you have a reasonably self-contained and easy way to (probablistically)
reproduce it?


        Stefan

Re: non-blocking connect

[Kai Grossjohann]

Stefan <monnier@iro.umontreal.ca> writes:

>> Difficult to say: it seems to depend on a libc/Emacs interaction.
>
> Do you have a reasonably self-contained and easy way to (probablistically)
> reproduce it?

Michael Albinus added code to the docstring of tramp-chunksize that
can be used to find out whether the problem is present in the current
Emacs/libc combination.  Is that good enough?

Kai

Re: non-blocking connect

[Richard Stallman]

You might be able to try debugging this by modifying various programs
used in the transmission, so that they compare the data being
transmitted against the correct contents of that file.  That way you
could at least determine where the corruption occurs.