Hi, dear ECL Developers
One of our usocket user found a strange issue of ECL (9.10.2)'s network function SB-BSD-SOCKETS:SOCKOPT-TCP-NODELAY:
(describe 'sb-bsd-sockets::sockopt-tcp-nodelay)
SB-BSD-SOCKETS:SOCKOPT-TCP-NODELAY - external symbol in SB-BSD-SOCKETS package ----------------------------------------------------------------------------- SB-BSD-SOCKETS:SOCKOPT-TCP-NODELAY [Function] -----------------------------------------------------------------------------
On Linux (2.6.18, 2.6.31), it can be read, but changing a socket's TCP_NODELAY socket option will cause a "Permission denied" error:
(require :sb-bsd-sockets) (setq socket (make-instance 'sb-bsd-sockets:inet-
socket :type :stream :protocol :tcp)) #<SB-BSD-SOCKETS:INET-SOCKET descriptor 3 43107648>
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
(setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) t)
Sockopt error: Permission denied Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (SETF (SB-BSD-SOCKETS:SOCKOPT- TCP-NODELAY SOCKET) T)] In: #<process SI:TOP-LEVEL 0000000000741f60>.
On Mac OS X (10.6 here), changing a socket's TCP_NODELAY socket option has no effect (but no error) and default value is T:
(require :sb-bsd-sockets) (setq socket (make-instance 'sb-bsd-sockets:inet-
socket :type :stream :protocol :tcp)) #<SB-BSD-SOCKETS:INET-SOCKET descriptor 3 4321522432>
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
(setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) nil)
T
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
I also tried SBCL 1.0.31 on Mac OS X, everything is fine there, and the default TCP_NODELAY value is NIL.
Old (don't know how old) ECL version has no such issue. I think this is a bug. I'm not familiar with ECL's source code, by checking "sockets.lisp", I can only find this:
(define-sockopt sockopt-tcp-nodelay "TCP_NODELAY" bool)
I'm thinking, how does ECL build process detect the actual value behind C macro/constant "TCP_NODELAY" defined in OS's C header file? (I know SBCL will actually include them to get the actual value of them). Is there any possibility that ECL 9.10.2 is using an "old" value of the C macro/constant TCP_NODELAY which caused OS's setsockopt () function set a wrong flag to current socket fd? Any way, it breaks usocket package now.
Help needed.
Regards,
Chun Tian (binghe)
Chun Tian wrote:
What's your OS environment
Linux wintermute 2.6.31-rc9-ARCH-CUSTOM #1 SMP PREEMPT Wed Sep 9 15:53:36 CEST 2009 i686 AMD Phenom(tm) 9600 Quad-Core Processor AuthenticAMD GNU/Linux
and ECL build options?
./configure --build=i686-pc-linux-gnu \ --prefix=/usr \ --with-tcp \ --with-clos-streams \ --with-serve-event \ --enable-shared \ --enable-unicode \ --enable-boehm=local \ --enable-threads \ --with-system-gmp \ --without-x \ --without-clx
And can you supply a simply test case code for this issue?
Yes. I load Drakma (1.0) via ASDF and execute
(drakma:http-request "http://www.gnu.org/")
I ask this because I can't reproduce it in my environment (ECL 9.10.2 (default build options), Mac OS X 10.6, Latest usocket trunk code). If you can help us re-produce this issue, we'll look into and try to fix it as soon as possible.
Thank you! :)
Leslie