libera/#commonlisp - IRC Chatlog
Search
22:20:36
antonv
directly to some TLS port, or to the unencrypted NNTP port 119 and then upgrade with STARTTLS command?
23:05:07
aeth
Afaik, usocket is the most popular, but having used it, it has a few annoying limitations in TCP that in my IRC bot tests basically lead me to ping out eventually (over the course of days, usually, I think, iirc).
23:06:26
aeth
Unfortunately, one of the other popular ones depends on something called 'libfixposix' (you know, so it can run on Solaris and NetBSD and stuff), which complicates things by adding in a(n obscure) C dependency.
23:13:21
aeth
The problem I've had with usocket is that it relies on CL streams. http://www.lispworks.com/documentation/HyperSpec/Body/c_stream.htm
23:14:42
aeth
To use it on bytes (i.e. any arbitrary encoding that you then decode) you depend on LISTEN
23:15:03
aeth
"Returns true if there is a character immediately available from input-stream; otherwise, returns false. On a non-interactive input-stream, listen returns true except when at end of file[1]. If an end of file is encountered, listen returns false. listen is intended to be used when input-stream obtains characters from an interactive device such as a keyboard."
23:16:21
aeth
The problem being "If an end of file is encountered, listen returns false." This means you might have disconnected and usocket knows this and the stream is now an EOF, but you are still LISTENing as if you might have a connection still.
23:16:38
antonv
This should depend on the protocol. I don't know the IRC protocol, but most of the protocols define a way for communicating parties to know exactly how many bytes to read.
23:16:48
aeth
there is no READ-CHAR-NO-HANG equivalent for bytes, but if you need to do the text decoding on your end, you have to do this as bytes instead of chars
23:20:18
aeth
Because LISTEN doesn't work properly for TCP but usocket relies on it, I have to write my own timeout where I do a hanging READ-BYTE to check for EOF (unless there's another way? it's non-obvious), but every now and then there's some kind of concurrency issue which eats a byte, which will eventually result in a missed ping
23:21:18
aeth
"Reading from a stream which has been closed at the remote end signals an END-OF-FILE condition, meaning that reading from the stream and detecting that condition is the way to do it." https://usocket.common-lisp.dev/api-docs.shtml
23:21:59
aeth
But reading hangs unless it's READ-CHAR-NO-HANG or guarded by LISTEN, which doesn't check for END-OF-FILE
23:30:46
aeth
looks like usocket is supposedly the successor to trivial-sockets according to its documentation, though. https://usocket.common-lisp.dev/
23:33:14
fiddlerwoaroof
fsocket ( https://github.com/fjames86/fsocket ) is a bit more complete in some ways
23:34:05
fiddlerwoaroof
I've been writing some code that needs to send and receive on multicast sockets and, afaict, there's no way to do this even with the no-portable sb-bsd-sockets library
23:44:34
antonv
aeth: maybe you could chose some other approach, I don't know - a bit difficult to follow your explanation because don't know your task and maybe never done such task. Why do you need LISTEN? Are you trying some kind of async-io, where one thread handles multiple connections?