Hi, Douglas
Thanks very much for participate our discussion!
Hello Chun,
I will supply a patch to implement all these soon.
I think no patch will be better, if exist (even internal) functions in SCL can be used directly. This is quite different from the UDP support (most important interface functions lost), and USOCKET doesn't want to support future SCL versions only, exist versions will be supported if possible.
P.S. Of course you can export or add any functions in SCL future versions freely, we'll try to follow your steps:)
The 'ext:connect-to-inet-socket timeout has been included for some time, and this is the timeout for the connection attempt alone and does not affect the returned socket.
Yes, I think that's the meaning of SOCKET-CONNECT's TIMEOUT keyword, just the timeout for the connection attempt alone.
In LispWorks, the COMM:OPEN-TCP-STREAM has three timeout-related keywords: TIMEOUT, READ-TIMEOUT, and WRITE-TIMEOUT. USOCKET's SOCKET- CONNECT just use the first, that's just good.
I think USOCKET should add SOCKET-OPTION and (SETF SOCKET-OPTION) interfaces for get/set the other socket options for post-created sockets, options which I can tell at this time will be:
* SO_KEEPALIVE * SO_REUSEADDR * SO_RCVTIMEO * SO_SNDTIMEO * TCP_NODELAY
One of them (SO_RCVTIMEO) is also useful for UDP sockets.
The stream timeout can be accessed using 'ext:stream-timeout, see: http://www.scieneer.com/scl/doc/function/ext/stream-timeout.html
What exact socket option does this function actually set? SO_RCVTIMEO or SO_SNDTIMEO, or both?
The stream deadline can be accessed using the 'ext:stream- expiration, see: http://www.scieneer.com/scl/doc/function/ext/stream-expiration.html
I see. Thanks!
Adding a 'socket-set-option would also work well. A 'nodelay argument can be added to 'ext:connect-to-inet-socket and/or 'ext:accept-tcp- connection if this is the preferred interface.
I think no need to add more keywords into EXT:CONNECT-TO-INET-SOCKET, for options we can set after socket creation, just use a separate function to set is just OK.
(The LOCAL-HOST and LOCAL-PORT keyword cannot be set after socket creation, so I requested to add them into EXT:CONNECT-TO-INET-SOCKET weeks ago.)
There are internal functions: 'ext::set-socket-option, and 'ext::set- socket-tcp-nodelay and one or both could be exported if it helps support usocket.
Great! And we (usocket) will try to use them (as internal functions).
Regards Douglas Crosher
Chun Tian (binghe) wrote:
Hi, Douglas By reading SCL 1.3.8 documents, I saw the TIMEOUT keyword in EXT:CONNECT-TO-INET-SOCKET, so I guess just use this keyword will be OK to add support for TIMEOUT in USOCKET:SOCKET-CONNECT. more questions:
- From which version of SCL, the TIMEOUT keyword be added? All SCL
version or there's some way we can detect whether TIMEOUT can be used? (i.e *features*, fboundp, ...) 2. How to support DEADLINE in SCL? (I can find details from SCL doc) 3. What if we (usocket) don't split out DEADLINE from SOCKET- CONNECT but add a new SET-SOCKET-OPTION to set the behavior of a already created socket? Regards, Chun Tian (binghe)
Hello Erik,
Thank you for the update.
The nodelay socket option can be supported in the Scieneer CL. It may also be useful to add this option to 'socket-accept, or perhaps split this out into a separate function that can be used to enable or disable the Nagle algorithm.
The Scieneer CL streams support both the timeout and the deadline, but also allow these to be reset and for the remaining time to be read which is important for many applications. For example a web server can reset the deadline at the start of a new request. So perhaps this functionality could be split out from 'socket-connect.
Regards Douglas Crosher
...
A number of smaller features (options to SOCKET-CONNECT) have also been added, however, these may not be available on all implementations:
- :no-delay, which disables Naggle's algorithm
- :timeout, which sets a per-operation timeout on the socket
- :deadline, which sets a maximum life-time to the socket
...
As always, any feedback - bugs or hugs - is greatly appreciated. If you use usocket, please let us know what for!
usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel