Hi List,
As datagram socket-receive generic function allows to pass extra key parameters, would it be possible to add extra timeout parameter for LispWorks backend? The attached patch adds this feature.
--ska
Hi, there
So, you want to override the default read time (when creating the usocket) sometime when you're calling SOCKET-RECEIVE. OK, extra keyword parameter is just for platform specific needs, you patch accepted as r571.
But if you take a look at my implementation of SOCKET-RECEIVE, you'll find the "temp" TIMEOUT keyword argument will be set into underlying socket by "setsockopt", and the previous default value will be set back when SOCKET-RECEIVE finishing it's work. Due to such double costs, I think this feature should not be used to much.
In next USOCKET versions, I'll provide a SOCKET-OPTION generic function to be able to set most socket options (include RCVTIMEO) after sockets were created, I hope this could fit your needs better.
--binghe
在 2010-12-8，13:31， Kamil Shakirov 写道：
Hi List,
As datagram socket-receive generic function allows to pass extra key parameters, would it be possible to add extra timeout parameter for LispWorks backend? The attached patch adds this feature.
--ska <0001-Receive-timeout.patch>_______________________________________________ usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Hi Chun,
On Wed, 2010-12-08 at 14:30 +0800, Chun Tian (binghe) wrote:
Hi, there
So, you want to override the default read time (when creating the usocket) sometime when you're calling SOCKET-RECEIVE. OK, extra keyword parameter is just for platform specific needs, you patch accepted as r571.
Thanks. In the current API neither socket-connect nor socket-receive methods use a timeout parameter for a datagram socket in LispWorks backend.
But if you take a look at my implementation of SOCKET-RECEIVE, you'll find the "temp" TIMEOUT keyword argument will be set into underlying socket by "setsockopt", and the previous default value will be set back when SOCKET-RECEIVE finishing it's work. Due to such double costs, I think this feature should not be used to much. In next USOCKET versions, I'll provide a SOCKET-OPTION generic function to be able to set most socket options (include RCVTIMEO) after sockets were created, I hope this could fit your needs better.
That would be the best way to control socket options.
--binghe
在 2010-12-8，13:31， Kamil Shakirov 写道：
Hi List,
As datagram socket-receive generic function allows to pass extra key parameters, would it be possible to add extra timeout parameter for LispWorks backend? The attached patch adds this feature.
--ska <0001-Receive-timeout.patch>_______________________________________________ usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
--ska
在 2010-12-8，15:54， Kamil Shakirov 写道：
Hi Chun,
On Wed, 2010-12-08 at 14:30 +0800, Chun Tian (binghe) wrote:
Hi, there
So, you want to override the default read time (when creating the usocket) sometime when you're calling SOCKET-RECEIVE. OK, extra keyword parameter is just for platform specific needs, you patch accepted as r571.
Thanks. In the current API neither socket-connect nor socket-receive methods use a timeout parameter for a datagram socket in LispWorks backend.
Oh my god, this is a bug, or feature lost. SOCKET-CONNECT *should* pass its keyword argument TIMEOUT to underlying UDP functions as a READ-TIMEOUT. The fact is not, I've fixed this now.
You may thought the TIMEOUT argument of SOCKET-CONNECT is a "connection timeout", but unfortunately we cannot control this, at least not on all supported platform (only Clozure CL support :read-timeout when doing TCP connections, never check how this is done). For TCP sockets, the TIMEOUT value will be passed to stream creation functions and will be the "read timeout" when user operating on those TCP streams. For UDP sockets, it should be treated as "read timeout", since we cannot control or usually no need to control "write timeout". Any way, I just follow the exist USOCKET API to fit UDP needs.
I committed another fixes for this (r572), which passed following simple test:
CL-USER 7 > (usocket:socket-connect "localhost" 10000 :timeout 3 :protocol :datagram) #<USOCKET:DATAGRAM-USOCKET 200A5973>
CL-USER 8 > (usocket::get-socket-receive-timeout (usocket:socket *)) 3.0
CL-USER 9 > (usocket:socket-connect "localhost" 10001 :protocol :datagram) #<USOCKET:DATAGRAM-USOCKET 200B83EB>
CL-USER 10 > (usocket::get-socket-receive-timeout (usocket:socket *)) 0.0
(above just show client-side UDP, but server-side UDP should work in the same way)
I still need to check all supported platform, and do the same thing. Hope this change could work for your current need.
Regards,
Chun Tian (binghe)
But if you take a look at my implementation of SOCKET-RECEIVE, you'll find the "temp" TIMEOUT keyword argument will be set into underlying socket by "setsockopt", and the previous default value will be set back when SOCKET-RECEIVE finishing it's work. Due to such double costs, I think this feature should not be used to much. In next USOCKET versions, I'll provide a SOCKET-OPTION generic function to be able to set most socket options (include RCVTIMEO) after sockets were created, I hope this could fit your needs better.
That would be the best way to control socket options.
Thanks a lot.
On Wed, 2010-12-08 at 16:18 +0800, Chun Tian (binghe) wrote:
在 2010-12-8，15:54， Kamil Shakirov 写道：
Hi Chun,
On Wed, 2010-12-08 at 14:30 +0800, Chun Tian (binghe) wrote:
Hi, there
So, you want to override the default read time (when creating the usocket) sometime when you're calling SOCKET-RECEIVE. OK, extra keyword parameter is just for platform specific needs, you patch accepted as r571.
Thanks. In the current API neither socket-connect nor socket-receive methods use a timeout parameter for a datagram socket in LispWorks backend.
Oh my god, this is a bug, or feature lost. SOCKET-CONNECT *should* pass its keyword argument TIMEOUT to underlying UDP functions as a READ-TIMEOUT. The fact is not, I've fixed this now.
You may thought the TIMEOUT argument of SOCKET-CONNECT is a "connection timeout", but unfortunately we cannot control this, at least not on all supported platform (only Clozure CL support :read-timeout when doing TCP connections, never check how this is done). For TCP sockets, the TIMEOUT value will be passed to stream creation functions and will be the "read timeout" when user operating on those TCP streams. For UDP sockets, it should be treated as "read timeout", since we cannot control or usually no need to control "write timeout". Any way, I just follow the exist USOCKET API to fit UDP needs.
I committed another fixes for this (r572), which passed following simple test:
CL-USER 7 > (usocket:socket-connect "localhost" 10000 :timeout 3 :protocol :datagram) #<USOCKET:DATAGRAM-USOCKET 200A5973>
CL-USER 8 > (usocket::get-socket-receive-timeout (usocket:socket *)) 3.0
CL-USER 9 > (usocket:socket-connect "localhost" 10001 :protocol :datagram) #<USOCKET:DATAGRAM-USOCKET 200B83EB>
CL-USER 10 > (usocket::get-socket-receive-timeout (usocket:socket *)) 0.0
(above just show client-side UDP, but server-side UDP should work in the same way)
I still need to check all supported platform, and do the same thing. Hope this change could work for your current need.
Regards,
Chun Tian (binghe)
But if you take a look at my implementation of SOCKET-RECEIVE, you'll find the "temp" TIMEOUT keyword argument will be set into underlying socket by "setsockopt", and the previous default value will be set back when SOCKET-RECEIVE finishing it's work. Due to such double costs, I think this feature should not be used to much. In next USOCKET versions, I'll provide a SOCKET-OPTION generic function to be able to set most socket options (include RCVTIMEO) after sockets were created, I hope this could fit your needs better.
That would be the best way to control socket options.
--ska
-
Chun Tian (binghe) -
Kamil Shakirov