Re: [Portableaserve-discuss] MCL and OpenMCL support

[Jochen S. <js...@da...>]

Am Mon, 2002-04-08 um 19.21 schrieb John DeSoi:
> Jochen,
> 
> >
> >- Another thing I added to the LispWorks ACL-SOCKET implementation is
> >   proper condition-handling. It now throws a SOCKET-ERROR condition like
> >   ACL and this condition object contains the error-code and the related
> >   keyword-identifier like ACL. Condition-handling like this is not
> >   _necessary_ to get AServe running but makes ACL-COMPAT more compatible
> >   to the ACL API. (should work in LW).
> 
> Does this take care of the error I keep seeing under LispWorks on NT 
> ("Error during socket operation 10054")? As I mentioned before, the 
> response always seems Ok when this comes up.

10054 is the WinSock Error code for "Connection Reset".
The new socket stuff will generate a condition of the condition-class
SOCKET-ERROR which the error-code slot set to 10054 and the identifier
set to :connection-reset. So the error will still occur - only the
reporting will contain more information.
AFAIU the error message of this concrete problem this seems to be an
error that occurs if the other the peer (the browser) timeouts its
connection. Most browsers seem to reset the connection and try again so
a new request will arrive then that can be handled.

> I'm wondering if there is some connection issue when logging the 
> request. I noticed with OpenMCL that sometimes the connection is 
> already closed when the logging occurs. So the IP address returned 
> for the connection would be nil and then an error would occur in 
> calling ipaddr-to-dotted. For now, I just modified ipaddr-to-dotted 
> for OpenMCL to deal with nil (it was broken anyway).

Hm... we could store the IP address in the stream object so that we can
access it too if the connection is down. To get chunking working and to
get the socket layer more compatible to ACL we should inherit our own
class from the implementations stream-classes.

In my actual LW code I use this classes

(defclass binary-socket-stream (chunked-stream-mixin comm:socket-stream)
())
(defclass input-binary-socket-stream (binary-socket-stream)())
(defclass output-binary-socket-stream (binary-socket-stream)())
(defclass bidirectional-binary-socket-stream (input-binary-socket-stream
output-binary-socket-stream)())

COMM:SOCKET-STREAM provides me with LispWorks' socket-layer and the
CHUNKED-STREAM-MIXIN is mixing in specialized versions of
STREAM-FILL-BUFFER and STREAM-FLUSH-BUFFER and CLOSE which handle input
and output chunking if enabled.

You could add a slot to such a class which contains the IP and which
gets filled by INITIALIZE-INSTANCE on BINARY-SOCKET-STREAM.

> >What do you and the others suggest me to do with that stuff?
> >
> 
> 
> I think it is up to you. I'm OK if you want to do further work and 
> testing before the next release. My interest in getting something out 
> is for MCL/OpenMCL feedback and perhaps to get some other folks 
> interested in working on the project (maybe some one else wants to 
> implement chunking support :). But I can do this by pointing to cvs 
> and providing an archive at mac.com for the cvs adverse.

I think we should try to get a new release ready. I will try to commit
my LW stuff like chunking, error-handling a.s.o. and I will add the
lw-buffering.lisp too so that others who want to try it can see how it
is intented and try themselves. I will not commit the changes to
acl-socket-cmu.lisp because it would break the system for CMUCL.
Interested ones can send me an email then I will send them my actual
acl-socket-cmu.lisp.

IMHO As soon as we see that the version in CVS works for the examples in
CMUCL, LW, MCL and OpenMCL we can announce a release.

ciao,
Jochen