From: Paul Guyot (pguyot_at_kallisys.net)
Date: Thu Nov 13 2003 - 11:12:00 PST
Aux environs du 13/11/03 à 18:07 +0100, sous le titre "Re: [NTLK]
Returning from defection", Marcel van der Boom prit sa plus belle
plume pour écrire les mots suivants:
>Found the 1.1 package, thanks.
>
>Here we go:
>
>./LaHotte
>Attente d'une connexion (BFFFF540-BFFFF570).
>[BFFFF5C0] Connexion tablie (BFFFF570)
>[BFFFF5C0] Connect sur le Newton de Marcel van der Boom
>D]../../DCL/Exceptions/TDCLException.cp:54> New Exception - 7 (0) at
>../../DCL/Link/Dock Commands/TDCLDockCommand.cp:72
>
>Exception au niveau du lien [BFFFF5C0]!
> >> TDCLEOFException (code: 7, erreur: 0) [../../DCL/Link/Dock
>Commands/TDCLDockCommand.cp:72]
>
>Indeed the error -4 on the newton.
>
>You mentioned this in your earlier messages. The newton and the linux
>machine are both on wireless as that is the only method i have now to
>get them to talk to eachother on the same subnet.
The exception you have on the server side is an end of file
exception, in other words, the Newton closed the connection (and this
wasn't expected).
I don't know exactly what this is linked with. The dock application
uses the low-level interface to the Newton Communication Toolbox. It
interacts this way to whatever the dock module tells it to do. With
TCP/IP modules (Thomas' or ours), it interacts with Newton Internet
Enabler. Under some circumstances, the function that reads the dock
command header fails because reading failed in the TCP/IP stack. The
failure is reported with a -4 error.
I don't recall exactly what I succeeded to do by playing around on
this bug. I think I might have succeeded to make it work by retrying,
but I'm not sure. A workaround for something that could very likely
be a bug in Newton Internet Enabler (it wouldn't be the last one)
could be to create a low-level endpoint that would work like a proxy,
calling NIE, and that would retry whenever the error occurs. I'm not
sure this workaround would work, though, because the error occurs
after a timeout and the other end could choke somehow. I think NIE
doesn't close the connection, the dock application does after the
error occurred (it actually throws an exception that is caught later).
I admit this bug is a big mistery. It nearly exclusively occurs with
browsing (we might have experienced it with keyboard protocol) and it
happens randomly, although when trying to connect to Toronto, I can
trigger it very frequently.
Concerning Zeroconf, the code for it in the DCL is based on MacOS X
libraries (frameworks). So it cannot compile on Linux. But you
probably could easily subclass the BSD socket class to add Zeroconf
support through some mechanism. The big problem with Zeroconf on
Linux is that there is no standard protocol to register services to a
single daemon running at startup. I won't insert here everything I
think about Stuart or the folks at Apple working on Rendezvous, but I
could double the size of this e-mail. The support in Mandrake Linux 8
or 9 is even problematic because it's a stupid simple daemon (tmdns),
running as root, reading its configuration from a file owned by root
and you cannot run your own service registration tool without killing
it first, which of course requires root priviledges. In other words,
you need to bribe the system administrator.
Paul
-- Philosophie de baignoire - consultations sur rendez-vous. NPDS/NewtonOS: http://newton.kallisys.net:8080/ Apache/FreeBSD: http://www.kallisys.com/ -- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries List FAQ/Etiquette/Terms: http://www.newtontalk.net/faq.html Official Newton FAQ: http://www.chuma.org/newton/faq/
This archive was generated by hypermail 2.1.5 : Thu Nov 13 2003 - 12:30:01 PST