From: <ign...@my...> - 2002-05-24 18:35:01
|
Hello! I've got a little problem with sockets. When I use socket:socket-connect and the site I want to connect to is down or non-existent it takes a forever till my program can continue. I think a solution would be for me if I could specify a timeout to socket-connect. Is that a missing feature or am I off the track? (I don't have experience in socket programming in any other language so it's possible I'm missing something obvious here.) How can I solve this situation? Thanks in advance. -- ignotus Microsoft -- programs so large they have weather |
From: Sam S. <sd...@gn...> - 2002-05-24 19:20:36
|
> * In message <87e...@my...> > * On the subject of "[clisp-list] socket-connect's timeout" > * Sent on Fri, 24 May 2002 20:34:30 +0200 > * Honorable ign...@my... writes: > > I think a solution would be for me if I could specify a timeout to > socket-connect. Is that a missing feature or am I off the track? At the moment, there is no way to do this, which, I think, is the only operation where blocking is inevitable now (we have socket-wait, socket-status and listen, which will help you avoid blocking in all other cases). This is a nice feature to have, so I would appreciate it if someone could tell me how to set connection timeout for a socket. I suspect that there is a setsockopt() option for that (SO_RCVTIMEO?), but I am not sure. Do we have a "dedicated TCP/IP guru" here? -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Bus error -- please leave by the rear door. |
From: Jason L. <low...@us...> - 2002-05-24 20:00:52
|
I don't think you can specify the connection timeout, exactly. You can roll your own by setting the socket to non-blocking (ioctl w/ FIONBIO) before calling "connect"; then if connect sets errno to EINPROGRESS you can use "select" with a timeout to implement your own connection timeout. Jason On Fri, 2002-05-24 at 13:20, Sam Steingold wrote: [snip] > is a nice feature to have, so I would appreciate it if someone > could tell me how to set connection timeout for a socket. I suspect > that there is a setsockopt() option for that (SO_RCVTIMEO?), but I am > not sure. Do we have a "dedicated TCP/IP guru" here? > > -- > Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux > <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> > <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> > Bus error -- please leave by the rear door. |
From: John J. <jjo...@2g...> - 2002-05-24 20:29:25
|
On 24 May 2002, Sam Steingold wrote: > > * In message <87e...@my...> > > * On the subject of "[clisp-list] socket-connect's timeout" > > * Sent on Fri, 24 May 2002 20:34:30 +0200 > > * Honorable ign...@my... writes: > > > > I think a solution would be for me if I could specify a timeout to > > socket-connect. Is that a missing feature or am I off the track? > > At the moment, there is no way to do this, which, I think, is the only > operation where blocking is inevitable now (we have socket-wait, > socket-status and listen, which will help you avoid blocking in all > other cases). > > This is a nice feature to have, so I would appreciate it if someone > could tell me how to set connection timeout for a socket. I suspect > that there is a setsockopt() option for that (SO_RCVTIMEO?), but I am > not sure. Do we have a "dedicated TCP/IP guru" here? Not that I'm an expert on this, but the last time I had to do this in C on linux, I used an alarm. The SO_SNDTIMEO and SO_RCVTIMEO options may or may not work in linux 2.4.x... I read conflicting reports. But I thought those timeouts were for use after the connection is opened. J* |
From: Sam S. <sd...@gn...> - 2002-05-24 20:41:57
|
> * In message <sa0...@gl...> > * On the subject of "Re: [clisp-list] socket-connect's timeout" > * Sent on 24 May 2002 15:20:27 -0400 > * I write: > > This is a nice feature to have, so I would appreciate it if someone > could tell me how to set connection timeout for a socket. > Do we have a "dedicated TCP/IP guru" here? Thanks to Jason and John for their insights! The fact that there are two very different suggestions is quite scary: it basically means that there is no standard way to do this. I wonder if any application actually does this. -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Don't use force -- get a bigger hammer. |
From: John W. <jjw...@ya...> - 2002-05-24 23:38:59
|
--- Sam Steingold <sd...@gn...> wrote: > Thanks to Jason and John for their insights! The fact that there > are two very different suggestions is quite scary: it basically > means that there is no standard way to do this. > > I wonder if any application actually does this. Yes. I implemented it for cmucl. See <http://lemonodor.com/archives/000019.html>. John Wiseman __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
From: John J. <jjo...@2g...> - 2002-05-25 00:27:01
|
On Fri, 24 May 2002, John Wiseman wrote: > --- Sam Steingold <sd...@gn...> wrote: > > > Thanks to Jason and John for their insights! The fact that there > > are two very different suggestions is quite scary: it basically > > means that there is no standard way to do this. > > > > I wonder if any application actually does this. > > Yes. I implemented it for cmucl. See > <http://lemonodor.com/archives/000019.html>. And somewhere in a Stevens book, I saw the alarm technique. I'll try to find an example. It looks like John Wiseman's suggestion is better though. J* |
From: Sam S. <sd...@gn...> - 2002-05-26 21:15:46
Attachments:
timeout.diff
|
all interested parties please try the appended patch. I tested it only on linux, so I am especially interested in what other platform users think. Specifically win32: what's the MS-way to do ioctl/FIONBIO? basically, I added the :timeout keyword arg to SOCKET-ACCEPT and SOCKET-CONNECT so that (socket-accept s :timeout x) == (if (socket-wait s x) (socket-accept s) (error 'timeout)) and similarly for SOCKET-CONNECT. Todd, this is not what you want, I know, you prefer the UNIX way of returning NIL instead of signaling an error. The lisp way (as I understand it) is to return a valid object or to signal an error. You can get the behavior you want using IGNORE-ERRORS, while a careless user might get stuck with SOCKET-CONNECT returning NIL here: (let ((s (socket-connect 80 "www.foo.com" :timeout 1))) (format s "GET /~2%") (read-all s)) if S is NIL, format will succeed, while READ-ALL will probably block trying to read from *STANDARD-INPUT*. -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Live free or die. |
From: Todd S. <ts...@op...> - 2002-05-26 23:48:53
|
Sam Steingold <sd...@gn...> writes: > basically, I added the :timeout keyword arg to SOCKET-ACCEPT and > SOCKET-CONNECT so that > > (socket-accept s :timeout x) == > > (if (socket-wait s x) > (socket-accept s) > (error 'timeout)) Given SOCKET-STATUS, this isn't really necessary for SOCKET-ACCEPT. Doesn't hurt, though. > and similarly for SOCKET-CONNECT. > > Todd, this is not what you want, I know, you prefer the UNIX way of > returning NIL instead of signaling an error. The lisp way (as I > understand it) is to return a valid object or to signal an error. > > You can get the behavior you want using IGNORE-ERRORS, while a careless > user might get stuck with SOCKET-CONNECT returning NIL here: > > (let ((s (socket-connect 80 "www.foo.com" :timeout 1))) > (format s "GET /~2%") > (read-all s)) > > if S is NIL, format will succeed, while READ-ALL will probably block > trying to read from *STANDARD-INPUT*. You've misunderstood what I want. I have no problem with (socket-connect ... :timeout N) signaling an error if the timeout expires, and I agree that's the right thing. But what I want is something different, namely some form of socket-connect which doesn't block, even in the success cases. The only way to do that is to have the C socket-connect not handle the timeout, but to always return a stream (which may not be fully connected yet). Then in lisp, you can either do (socket-status (stream . output) N) and signal an error if the stream isn't fully connected within your timeout, or you can put the not-fully-connected stream into your state machine, if you happen to be trying to write a non-blocking TCP server and you don't have threads. Either way, the C socket-connect always either returns a valid object or signals an error. If a user were to try to use the not fully connected stream, they'd just end up blocking at that point. But you wouldn't expose users to this by default. Since the non-blocking semantics are different from the existing behavior, I was suggesting that the C SOCKET-CONNECT be renamed to SOCKET-CONNECT%, and then write the normal SOCKET-CONNECT in lisp. That way users would see the behavior you're talking about, but people can still get a true non-blocking socket-connect if they want it. Does that make any more sense? Todd |
From: Arseny S. <am...@ic...> - 2002-05-27 03:02:20
|
Hello, Monday, May 27, 2002, 9:48:03 AM, you wrote: Todd> You've misunderstood what I want. I have no problem with Todd> (socket-connect ... :timeout N) signaling an error if the timeout Todd> expires, and I agree that's the right thing. But what I want is Todd> something different, namely some form of socket-connect which doesn't Todd> block, even in the success cases. By analogy with socket-wait it can be (socket-connect .. :timeout 0) (but socket-wait has &optional, not &keyword timeout). But Sam's patch turns off blocking - doesn't it result in wrong recv/read/send/write handling ? BTW I believe, Berkeley guys wasn't so stupid to not implement TCP/IP on existing file API if it was possible. I mean, I think, if we working with sockets as with streams we should be ready wor some lack of functionality. OTOH that lack of functionality can result in big gain in generality thus speed of development, maintainability (at Lisp layer) etc. -- Best regards, Arseny mailto:am...@ic... |
From: Todd S. <ts...@op...> - 2002-05-27 05:10:01
|
Arseny Slobodjuck <am...@ic...> writes: > Hello, > > Monday, May 27, 2002, 9:48:03 AM, you wrote: > > Todd> You've misunderstood what I want. I have no problem with > Todd> (socket-connect ... :timeout N) signaling an error if the timeout > Todd> expires, and I agree that's the right thing. But what I want is > Todd> something different, namely some form of socket-connect which doesn't > Todd> block, even in the success cases. > > By analogy with socket-wait it can be (socket-connect .. :timeout 0) > (but socket-wait has &optional, not &keyword timeout). Correct me if I'm wrong, but using socket-connect with :timeout 0 will (virtually) always signal an error, since you'll never get connected instantly. (Perhaps you would on loopback.) That is not what I want. > But Sam's patch turns off blocking - doesn't it result in wrong > recv/read/send/write handling ? If it doesn't turn blocking back on, which it seems it doesn't, then yes, that's a problem that needs to be fixed regardless. > BTW I believe, Berkeley guys wasn't so stupid to not implement TCP/IP > on existing file API if it was possible. I mean, I think, if we > working with sockets as with streams we should be ready wor some > lack of functionality. OTOH that lack of functionality can result in > big gain in generality thus speed of development, maintainability (at > Lisp layer) etc. The flip side of that is that they give you all those socket options, non-blocking handles, etc., if you didn't actually _need_ them sometimes. I have no problem with the normal interfaces in clisp picking sane defaults for that stuff. I do have a problem with the fact that there's no way to workaround them without completely abandoning the provided interfaces, and starting from scratch with linux:socket, linux:connect, etc. Todd |
From: Arseny S. <am...@ic...> - 2002-05-27 12:08:11
|
Hello Sam, Monday, May 27, 2002, 7:16:21 AM, you wrote: Sam> Specifically win32: what's the MS-way to do ioctl/FIONBIO? They call it WSPIoctl. IIUC it should be errorp = WSPIoctl(socket,FIONBIO,&unsigned_long_nonblockp, sizeof(unsigned_long_nonblockp),NULL,0,NULL,NULL,NULL,NULL,&errno_returned); But it needs experimenting. -- Best regards, Arseny mailto:am...@ic... |
From: Sam S. <sd...@gn...> - 2002-05-27 16:31:08
|
> * In message <682...@ic...> > * On the subject of "Re[2]: [clisp-list] socket-connect's timeout" > * Sent on Mon, 27 May 2002 22:00:57 +1000 > * Honorable Arseny Slobodjuck <am...@ic...> writes: > > Monday, May 27, 2002, 7:16:21 AM, you wrote: > > Sam> Specifically win32: what's the MS-way to do ioctl/FIONBIO? > They call it WSPIoctl. IIUC it should be > > errorp = WSPIoctl(socket,FIONBIO,&unsigned_long_nonblockp, > sizeof(unsigned_long_nonblockp),NULL,0,NULL,NULL,NULL,NULL,&errno_returned); > > But it needs experimenting. great! please make win32.d and win32aux.d export a non-interruptible ioctl, just like unix.d and unixaux.d do. -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> If your VCR is still blinking 12:00, you don't want Linux. |
From: Arseny S. <am...@ic...> - 2002-05-27 12:08:11
|
Hello Todd, Monday, May 27, 2002, 3:08:26 PM, you wrote: >> Todd> You've misunderstood what I want. I have no problem with >> Todd> (socket-connect ... :timeout N) signaling an error if the timeout >> Todd> expires, and I agree that's the right thing. But what I want is >> Todd> something different, namely some form of socket-connect which doesn't >> Todd> block, even in the success cases. >> >> By analogy with socket-wait it can be (socket-connect .. :timeout 0) >> (but socket-wait has &optional, not &keyword timeout). Todd> Correct me if I'm wrong, but using socket-connect with :timeout 0 will Todd> (virtually) always signal an error, since you'll never get connected Todd> instantly. (Perhaps you would on loopback.) That is not what I want. Yes, you're right. But socket-wait doesn't return an error - it polls (and it's convenient). What if we'll have analog of socket-wait but for client side - call it, say connect-wait or wait-connect or client-wait... It will turn blocking off, starts connecting (if connection wasn't started yet), waits checking whether connection ready and returns nil or t depending on result. Then socket-connect (when called) checks the status, turns on the blocking and signals an error or returns stream in full harmony with Lisp spirit balancing Client and Server sides of Connection... How do you like it ? -- Best regards, Arseny mailto:am...@ic... |
From: Todd S. <ts...@op...> - 2002-05-27 15:42:26
|
Arseny Slobodjuck <am...@ic...> writes: > Todd> Correct me if I'm wrong, but using socket-connect with :timeout 0 will > Todd> (virtually) always signal an error, since you'll never get connected > Todd> instantly. (Perhaps you would on loopback.) That is not what I want. > Yes, you're right. But socket-wait doesn't return an error - it polls (and > it's convenient). What if we'll have analog of socket-wait but for client > side - call it, say connect-wait or wait-connect or client-wait... It will > turn blocking off, starts connecting (if connection wasn't started yet), > waits checking whether connection ready and returns nil or t depending on > result. Then socket-connect (when called) checks the status, turns on the > blocking and signals an error or returns stream in full harmony with Lisp > spirit balancing Client and Server sides of Connection... How do you > like it ? Well, I'm not very clear on how your proposal would work. What would you pass to SOCKET-CONNECT to indicate that you want to use whatever it is you get from CLIENT-WAIT? And I don't really want a separate function for the waiting. I want to be able to take <whatever it is> and use in with socket-status, along with all the other open connections my server is processing. What about the idea of having a SOCKET-CONNECT% didn't you like? I don't suppose it makes sense to re-suggest the stuff in: http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? Sam already shot that down, but it's another way of dealing with this, as well as providing UDP sockets, unix domain sockets, etc. To tell the truth, I've already implemented most of that locally. It needs some refinement, but works just fine. Todd |
From: Sam S. <sd...@gn...> - 2002-05-27 16:20:49
|
> * In message <m3v...@je...> > * On the subject of "Re: Re[4]: [clisp-list] socket-connect's timeout" > * Sent on 27 May 2002 11:41:21 -0400 > * Honorable Todd Sabin <ts...@op...> writes: > > What about the idea of having a SOCKET-CONNECT% didn't you like? KISS - keep it simple. first, this is not really necessary. if we really will introduce the "half-baked streams" (i.e., streams that will start any i/o operation with a connect() syscall), they can be created when the timeout is 0 (i.e. when otherwise we are guaranteed to get an error). second, I am not sure these "half-baked streams" are a good isea. what do you need them for? > I don't suppose it makes sense to re-suggest the stuff in: > http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? here is the problem. I _know_ what you want: you want, basically, bindings/linuxlibc6 in CLISP at all times on all platforms (this is actually what I wanted when I added --with-export-syscalls). Therefore anything short of that will not satisfy you, and a lot of that will not be portable (even across unixes) and will not work too well with the traditional Lisp paradigms, therefore this SOCKET-CONNECT% (which should actually be %SOCKET-CONNECT! :-) will not be enough for you and will be too much for "lisp purists" :-( > Sam already shot that down, but it's another way of dealing with this, > as well as providing UDP sockets, unix domain sockets, etc. To tell > the truth, I've already implemented most of that locally. It needs > some refinement, but works just fine. good. first, wrap it into `#ifdef EXPORT_SYSCALLS'. second, please do try to go a step up from bindings/linuxlibc6: a lot of stuff here can be unified in one function (e.g., FILE-STAT unifies lstat() and fstat()). third, provide a way to get back into the Lisp world, i.e., something like `sys:make-fd-stream' in CMUCL to convert a socket to a stream. (BTW, since the word `socket' is already overused, please call your new type `handle'). -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Press any key to continue or any other key to quit. |
From: Arseny S. <am...@ic...> - 2002-05-27 22:23:37
|
Hello Sam, Tuesday, May 28, 2002, 2:31:47 AM, you wrote: >> Sam> Specifically win32: what's the MS-way to do ioctl/FIONBIO? >> They call it WSPIoctl. IIUC it should be >> >> errorp = WSPIoctl(socket,FIONBIO,&unsigned_long_nonblockp, >> sizeof(unsigned_long_nonblockp),NULL,0,NULL,NULL,NULL,NULL,&errno_returned); >> But it needs experimenting. Sam> great! please make win32.d and win32aux.d export a non-interruptible Sam> ioctl, just like unix.d and unixaux.d do. Ok, in a day or two. -- Best regards, Arseny mailto:am...@ic... |
From: Arseny S. <am...@ic...> - 2002-05-27 22:23:54
|
Hello Todd, Tuesday, May 28, 2002, 1:41:21 AM, you wrote: >> Todd> Correct me if I'm wrong, but using socket-connect with :timeout 0 will >> Todd> (virtually) always signal an error, since you'll never get connected >> Todd> instantly. (Perhaps you would on loopback.) That is not what I want. >> Yes, you're right. But socket-wait doesn't return an error - it polls (and >> it's convenient). What if we'll have analog of socket-wait but for client >> side - call it, say connect-wait or wait-connect or client-wait... It will >> turn blocking off, starts connecting (if connection wasn't started yet), >> waits checking whether connection ready and returns nil or t depending on >> result. Then socket-connect (when called) checks the status, turns on the >> blocking and signals an error or returns stream in full harmony with Lisp >> spirit balancing Client and Server sides of Connection... How do you >> like it ? Todd> Well, I'm not very clear on how your proposal would work. What would Todd> you pass to SOCKET-CONNECT to indicate that you want to use whatever Todd> it is you get from CLIENT-WAIT? You're right again. Then we need a CLIENT-SOCKET datatype analogous to SERVER-SOCKET and initializer for it (taking port and host parameters). Then initializer starts connection, CLIENT-WAIT waits or polls and CLIENT-CONNECT creates the stream or throws an error. Todd> What about the idea of having a SOCKET-CONNECT% didn't you like? Think about it as about your half-connected streams splitted into half-connected part (CLIENT-SOCKET) and connected SOCKET-STREAM. That's just in more agreement with things existing before (as far I can see). Todd> I don't suppose it makes sense to re-suggest the stuff in: Todd> http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? I think those people who don't want to know about blocking, UDP sockets, ioctl etc have right to it. So let advanced interface exists, but if it hurts basic interface - maybe make it separate from SOCKET: ? -- Best regards, Arseny mailto:am...@ic... |
From: Todd S. <ts...@op...> - 2002-05-28 16:20:37
|
Sam Steingold <sd...@gn...> writes: > > What about the idea of having a SOCKET-CONNECT% didn't you like? > > KISS - keep it simple. > > first, this is not really necessary. > if we really will introduce the "half-baked streams" (i.e., streams that > will start any i/o operation with a connect() syscall), I think you may have misunderstood again. They wouldn't start any i/o with a connect call. The connect call would already have been made, but in non-blocking mode. If you were to try to use the socket/stream without waiting (via SOCKET-STATUS) for the connect to finish, then it would just block at that point. There'd be no need to modify any of the current read/write paths. > they can be > created when the timeout is 0 (i.e. when otherwise we are guaranteed to > get an error). This would work for me. > second, I am not sure these "half-baked streams" are a good isea. > what do you need them for? I've already explained several times, but I'll try again. Imagine you're writing a proxy server. You accept connections from clients, and in the process of servicing them, you have to open connections to the resources they're requesting. Unless you consider it acceptable for your proxy to be totally non-responsive for large periods of time, you've got to have a non-blocking connect. The only representation in clisp for a socket connection is a socket-stream. Therefore, you need a non-blocking way of getting a socket-stream which you can then use with socket-status. Is that clear enough? > > I don't suppose it makes sense to re-suggest the stuff in: > > http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? > > here is the problem. > I _know_ what you want: you want, basically, bindings/linuxlibc6 in > CLISP at all times on all platforms (this is actually what I wanted when > I added --with-export-syscalls). Therefore anything short of that will > not satisfy you, and a lot of that will not be portable (even across > unixes) and will not work too well with the traditional Lisp paradigms, Please stop assuming you know what I want. What I'm saying in that email is that I want _sockets_, not all of linuxlibc6, on all platforms. Are there any clisp-supported platforms that don't support, say, UDP sockets? If not, why not make them standard in clisp? Why should people be forced to resort to FFI? I think there is a basic set of socket functionality which is available on all platforms (socket, bind, listen, accept, connect, recvfrom, sendto, e.g.). And that providing that, and then building higher level stuff on top of it would provide people with far more functionality and options than they currently have. Do you disagree with the feasability of that? If so, are there specific problems you know of? > > Sam already shot that down, but it's another way of dealing with this, > > as well as providing UDP sockets, unix domain sockets, etc. To tell > > the truth, I've already implemented most of that locally. It needs > > some refinement, but works just fine. > > good. > first, wrap it into `#ifdef EXPORT_SYSCALLS'. I think #ifdef FULL_SOCKETS or something would be more appropriate. > second, please do try to go a step up from bindings/linuxlibc6: a lot > of stuff here can be unified in one function (e.g., FILE-STAT unifies > lstat() and fstat()). As I said, this is a non-issue for me. > third, provide a way to get back into the Lisp world, i.e., something > like `sys:make-fd-stream' in CMUCL to convert a socket to a stream. Yes, this is really the crux of the problem. There's currently no way to get back into the normal lisp world. What I did for now was to expose make_socket_stream as MAKE-SOCKET-STREAM% (should be %MAKE...). If you agree that (or something similar) is necessary, and if you agree that the basic socket functionality can be exposed portably (though perhaps you don't), then you're 95% of the way to what I was suggesting in that email. At least, maybe you understand where I'm coming from now? E.g., given the above, I wouldn't care about clisp not providing the non-blocking connect, because I could easily add it myself at the lisp layer. And the same would be true of lots of other socket functionality. Todd |
From: Sam S. <sd...@gn...> - 2002-05-28 17:13:07
|
> * In message <m3r...@je...> > * On the subject of "Re: Re[4]: [clisp-list] socket-connect's timeout" > * Sent on 28 May 2002 12:19:34 -0400 > * Honorable Todd Sabin <ts...@op...> writes: > > Sam Steingold <sd...@gn...> writes: > > > What about the idea of having a SOCKET-CONNECT% didn't you like? > > > > KISS - keep it simple. > > > > first, this is not really necessary. > > if we really will introduce the "half-baked streams" (i.e., streams that > > will start any i/o operation with a connect() syscall), > > They wouldn't start any i/o with a connect call. The connect call > would already have been made, but in non-blocking mode. are you saying that the second connect() call in connect_via_ip() is wrong? why didn't you say that?! > If you were to try to use the socket/stream without waiting (via > SOCKET-STATUS) for the connect to finish, then it would just block at > that point. There'd be no need to modify any of the current > read/write paths. when do I put the socket back into the blocking mode? right after connect() but before the first i/o operation? > > they can be > > created when the timeout is 0 (i.e. when otherwise we are guaranteed to > > get an error). > > This would work for me. you got it - try the appended patch with the current CVS (preferably _before_ replying to this message :-). please comment on the code - you know more about TCP/IP than I do. > > > I don't suppose it makes sense to re-suggest the stuff in: > > > http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? > > > > here is the problem. > > I _know_ what you want: you want, basically, bindings/linuxlibc6 in > > CLISP at all times on all platforms (this is actually what I wanted when > > I added --with-export-syscalls). Therefore anything short of that will > > not satisfy you, and a lot of that will not be portable (even across > > unixes) and will not work too well with the traditional Lisp paradigms, > > Please stop assuming you know what I want. What I'm saying in that > email is that I want _sockets_, not all of linuxlibc6, on all > platforms. Are there any clisp-supported platforms that don't > support, say, UDP sockets? If not, why not make them standard in > clisp? Why should people be forced to resort to FFI? so I exaggerated a bit. you only want sockets. fine. BTW, does a stream based on a UDP socket make sense? if yes, could we make it an option for socket-connect and socket-accept? > I think there is a basic set of socket functionality which is > available on all platforms (socket, bind, listen, accept, connect, > recvfrom, sendto, e.g.). And that providing that, and then building > higher level stuff on top of it would provide people with far more > functionality and options than they currently have. Do you disagree > with the feasability of that? If so, are there specific problems you > know of? win32. will your code work _the same way_ on all Unixes and on w32? > > first, wrap it into `#ifdef EXPORT_SYSCALLS'. > I think #ifdef FULL_SOCKETS or something would be more appropriate. EXPORT_SYSCALLS corresponds to a configure option already. > > third, provide a way to get back into the Lisp world, i.e., something > > like `sys:make-fd-stream' in CMUCL to convert a socket to a stream. > > Yes, this is really the crux of the problem. There's currently no way > to get back into the normal lisp world. What I did for now was to > expose make_socket_stream as MAKE-SOCKET-STREAM% (should be %MAKE...). > If you agree that (or something similar) is necessary, and if you > agree that the basic socket functionality can be exposed portably > (though perhaps you don't), then you're 95% of the way to what I was > suggesting in that email. At least, maybe you understand where I'm > coming from now? okay - send a patch doing what you want. it should work both on UNIX and win32. -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Failure is not an option. It comes bundled with your Microsoft product. --- socket.d.~1.59.~ Tue May 28 04:11:10 2002 +++ socket.d Tue May 28 13:03:18 2002 @@ -823,6 +823,8 @@ return fd; #ifdef FIONBIO if (sock_errno_is(EINPROGRESS)) { + var struct timeval *tv = (struct timeval*)timeout; + if (tv==NULL || tv->tv_sec!=0 || tv->tv_usec!=0) { # wait restart_select: var fd_set handle_set; FD_ZERO(&handle_set); FD_SET(fd,&handle_set); @@ -836,8 +838,8 @@ CLOSESOCKET(fd); errno = ETIMEDOUT; return INVALID_SOCKET; } - if (connect(fd, addr, addrlen) >= 0) { - # connected - restore blocking IO + } + { # connected - restore blocking IO var int non_blocking_io = 0; if (ioctl(fd,FIONBIO,&non_blocking_io) == 0) return fd; |
From: Todd S. <ts...@op...> - 2002-05-28 16:34:09
|
Arseny Slobodjuck <am...@ic...> writes: > Hello Todd, > > Tuesday, May 28, 2002, 1:41:21 AM, you wrote: > > >> Todd> Correct me if I'm wrong, but using socket-connect with :timeout 0 will > >> Todd> (virtually) always signal an error, since you'll never get connected > >> Todd> instantly. (Perhaps you would on loopback.) That is not what I want. > >> Yes, you're right. But socket-wait doesn't return an error - it polls (and > >> it's convenient). What if we'll have analog of socket-wait but for client > >> side - call it, say connect-wait or wait-connect or client-wait... It will > >> turn blocking off, starts connecting (if connection wasn't started yet), > >> waits checking whether connection ready and returns nil or t depending on > >> result. Then socket-connect (when called) checks the status, turns on the > >> blocking and signals an error or returns stream in full harmony with Lisp > >> spirit balancing Client and Server sides of Connection... How do you > >> like it ? > > Todd> Well, I'm not very clear on how your proposal would work. What would > Todd> you pass to SOCKET-CONNECT to indicate that you want to use whatever > Todd> it is you get from CLIENT-WAIT? > You're right again. Then we need a CLIENT-SOCKET datatype analogous to > SERVER-SOCKET and initializer for it (taking port and host parameters). > Then initializer starts connection, CLIENT-WAIT waits or polls and > CLIENT-CONNECT creates the stream or throws an error. > > Todd> What about the idea of having a SOCKET-CONNECT% didn't you like? > Think about it as about your half-connected streams splitted into > half-connected part (CLIENT-SOCKET) and connected SOCKET-STREAM. > That's just in more agreement with things existing before (as far I can > see). Ah. This is actually extremely close to what I mention in the email referenced below. Your CLIENT-SOCKET would just be a normal SOCKET, and what you are calling CLIENT-CONNECT would be more like a MAKE-SOCKET-STREAM. I.e., something that takes a socket and makes a stream from it. > Todd> I don't suppose it makes sense to re-suggest the stuff in: > Todd> http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? > I think those people who don't want to know about blocking, UDP > sockets, ioctl etc have right to it. So let advanced interface exists, > but if it hurts basic interface - maybe make it separate from SOCKET: ? I don't understand why you think this would force complexity on people who don't want it. If you want to keep using the high level stuff that's there now, you can. People who want to use the current stuff aren't forced to look at the C implementation, are they? All I'm saying is to move some of the C code to lisp. But it'd still be "implementation details" people can ignore if they want. Todd |
From: Sam S. <sd...@gn...> - 2002-05-28 17:51:00
|
> * In message <m3n...@je...> > * On the subject of "Re: Re[6]: [clisp-list] socket-connect's timeout" > * Sent on 28 May 2002 12:33:07 -0400 > * Honorable Todd Sabin <ts...@op...> writes: > > > Todd> I don't suppose it makes sense to re-suggest the stuff in: > > Todd> http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? > > I think those people who don't want to know about blocking, UDP > > sockets, ioctl etc have right to it. So let advanced interface exists, > > but if it hurts basic interface - maybe make it separate from SOCKET: ? > > I don't understand why you think this would force complexity on people > who don't want it. If you want to keep using the high level stuff > that's there now, you can. People who want to use the current stuff > aren't forced to look at the C implementation, are they? All I'm > saying is to move some of the C code to lisp. But it'd still be > "implementation details" people can ignore if they want. the exported socket API will have many more functions, and this _will_ be confusing for an average user. -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Binaries die but source code lives forever. |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2002-05-28 19:41:40
|
Sam Steingold writes: > > * In message <m3n...@je...> > > * On the subject of "Re: Re[6]: [clisp-list] socket-connect's timeout" > > * Sent on 28 May 2002 12:33:07 -0400 > > * Honorable Todd Sabin <ts...@op...> writes: > > > > > Todd> I don't suppose it makes sense to re-suggest the stuff in: > > > Todd> http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? > > > I think those people who don't want to know about blocking, UDP > > > sockets, ioctl etc have right to it. So let advanced interface exists, > > > but if it hurts basic interface - maybe make it separate from SOCKET: ? > > > > I don't understand why you think this would force complexity on people > > who don't want it. If you want to keep using the high level stuff > > that's there now, you can. People who want to use the current stuff > > aren't forced to look at the C implementation, are they? All I'm > > saying is to move some of the C code to lisp. But it'd still be > > "implementation details" people can ignore if they want. > > the exported socket API will have many more functions, > and this _will_ be confusing for an average user. Only if you document it as one big API. The other option is to document it in layers. Have a "High-Level Sockets API" section followed by a "Low-Level Sockets API" section. I'm pretty sure that most users will stop reading at the end of the high-level section, when they figure out they can do what they want with it. -- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----' |
From: Arseny S. <am...@ic...> - 2002-05-28 22:48:28
|
Hello, Sam, Wednesday, May 29, 2002, 3:12:43 AM, you wrote: >> They wouldn't start any i/o with a connect call. The connect call >> would already have been made, but in non-blocking mode. Sam> are you saying that the second connect() call in connect_via_ip() is Sam> wrong? why didn't you say that?! I tried your patch on win32 (with ioctl changed to win32 equivalent - I found 'ioctlsocket(socked,cmd,arg)' function in API) and it works not very well. I am quite busy to debug it fast, but we're not in a hurry, are we ? Or better yet I will debug it after unix version will work (basically it works, but when I'm emulating slow server responce, it fails. I patched it and now it locks at all). -- Best regards, Arseny mailto:am...@ic... |
From: Arseny S. <am...@ic...> - 2002-05-25 00:43:39
|
Hello Sam, Saturday, May 25, 2002, 6:41:49 AM, you wrote: >> This is a nice feature to have, so I would appreciate it if someone >> could tell me how to set connection timeout for a socket. >> Do we have a "dedicated TCP/IP guru" here? Sam> Thanks to Jason and John for their insights! Sam> The fact that there are two very different suggestions is quite scary: Sam> it basically means that there is no standard way to do this. IANATCPIPG, but Jason's approach seems standard - it's already used in socket-wait. MSDN: connect ..... If no error occurs, connect returns zero. Otherwise, it returns SOCKET_ERROR, and a specific error code can be retrieved by calling WSAGetLastError. On a blocking socket, the return value indicates success or failure of the connection attempt. With a nonblocking socket, the connection attempt cannot be completed immediately. In this case, connect will return SOCKET_ERROR, and WSAGetLastError will return WSAEWOULDBLOCK. In this case, there are three possible scenarios: -- Use the select function to determine the completion of the connection request by checking to see if the socket is writeable. -- ... (windows specific) -- ... (windows specific) -- Best regards, Arseny mailto:am...@ic... |