I imagine you have installed i2pd (pkg_add i2pd) and either left its
defaults intact, or are comfortable yourself. I hope you also have a normal
openbsd netcat (nc). There is a socks5 (I guess?) tcp tunnel to a port
broadcast as port 70 over i2p. In particular it is that a+b-c.lisp date app
from yesterday (except talking to a usocket tcp stream). I have two one
second pauses because #'force-output seems to need to be waited for, and
#'finish-output doesn't seem to do what I want. And forming the i2p
connection seems to take a few seconds already.
I am serving a slightly liberally minded item type 7. The rule for item type
7 is that you send the item specifier followed by a tab. Here, now I am
telling you that the item specifier is
7looking for:
followed by a literal tab. Item type 7 is handled by the server by reading a
line (until a double? CRLF I think). I am a bit badly behaved in that I just
attempt 3 (optional) lisp READs (*read-eval* nil). Those can be time
specifiers that look kind of like what you get if you don't send anything.
So minimally:
One bug for me is that if you send a newline, my app thinks you're trying to
send a date specifier like ((hour . 3))\n and tries to wait for you. Please
hang up on your own in that case ;p. The EOF from not sending a newline
works as a newline which is why cutting off after the \t works.
If it's useful, you are welcome to use it. If it has too much interference
I'll patch it... I guess it should really be an inetd thing to take
advantage of inetd's behaviors. I do log (get-universal-time) when I receive
a connection, and it is possible that when an error happens what you send
might show up in my logs, but generally I am not attempting to log time
queries.
