CL-Telnetd is a joke: "I still haven't even compiled this so I have no
clue whether those even work yet, but who cares."
Anyone know of a working lisp telnetd? What I need is something that
will service N incoming connections and just hook them up to a stream.
I've been using trivial-sockets (after perturbing it to add a
buffering keyword in cmucl), works fine for a single connection
(thanks danb!).
--
LOOP :: a Domain Specific Language.
GP lisper <········@CloudDancer.com> writes:
> Anyone know of a working lisp telnetd?
I do not. But telnet is one of the simpler protocols. I've considred
writing a telnet front end for a web based application. My
consideration was very much squelched when I discussed the idea with a
friend. My idea was to use the telnet protocol for a text based
MMORPG (or are those called MUDs?) Anywho, it's something that I'm
not likely to do.
I've written a whois client in Perl as well as a finger client. The
RFC for telnet can't be that much more involved.
--
(when (or hope despair)
(error "Deal with life as it is."))
David Steuber <·····@david-steuber.com> writes:
> GP lisper <········@CloudDancer.com> writes:
>
> > Anyone know of a working lisp telnetd?
>
> I do not. But telnet is one of the simpler protocols.
Not really.
> I've written a whois client in Perl as well as a finger client. The
> RFC for telnet can't be that much more involved.
It's actually pretty complicated. See RFCs 854 and 1143, for example.
Zach
On 14 Jul 2005 13:28:06 -0400, <·····@david-steuber.com> wrote:
>
> GP lisper <········@CloudDancer.com> writes:
>
>> Anyone know of a working lisp telnetd?
>
> I do not. But telnet is one of the simpler protocols. I've considred
> writing a telnet front end for a web based application. My
> consideration was very much squelched when I discussed the idea with a
> friend. My idea was to use the telnet protocol for a text based
> MMORPG (or are those called MUDs?) Anywho, it's something that I'm
> not likely to do.
Funny, most text-based Muds are telnet based. Why did your friend
kill your idea?
> I've written a whois client in Perl as well as a finger client. The
> RFC for telnet can't be that much more involved.
Finger or Whois are essentially a single connection, squirt some info
down the pipe and disconnect. A hard part of telnetd is serving
multiple connections.
After looking into my application some more, if I had something like
(append-broadcast-stream broadcast-stream new-stream)
that worked without resetting any of the existing stream states, I can
get the rest working.
--
LOOP :: a Domain Specific Language.
GP lisper <········@clouddancer.com> wrote:
+---------------
| Finger or Whois are essentially a single connection, squirt some info
| down the pipe and disconnect. A hard part of telnetd is serving
| multiple connections.
+---------------
Sorry to contradict, but that's the *easy* part! The hard part of
doing a *real* "telnetd" is handling all the fiddly DO/DONT/WILL/WONT
commands (called "options" in the Telnet spec, but many of them are
not at all optional), and especially their negotiations. And then
there's the need to have hooks into the underlying TCP's "urgent
pointer" mechanism to handle interrupt-type Telnet commands.
People here on comp.lang.lisp somtimes complain that the Common Lisp
pathname mechanism was designed to accomodate the vagaries of
"strange operating systems that nobody uses anymore". Hah! You
ain't seen *nuttin'* in the way of supporting "strange operating
systems" 'til you try to do a complete implementation of Telnet!
Start by implementing RFCs 854 & 855, then implement all the RFCs
with the pattern "Telnet.*Option" in the title, some 50+ of them
[I may have missed a few]:
RFC 651 Revised Telnet status option.
652 Telnet output carriage-return disposition option.
653 Telnet output horizontal tabstops option.
654 Telnet output horizontal tab disposition option.
655 Telnet output formfeed disposition option.
656 Telnet output vertical tabstops option.
657 Telnet output vertical tab disposition option.
659 Announcing additional Telnet options.
698 Telnet extended ASCII option.
726 Remote Controlled Transmission and Echoing Telnet option.
727 Telnet logout option.
729 Telnet byte macro option.
731 Telnet Data Entry Terminal option.
732 Telnet Data Entry Terminal option.
735 Revised Telnet byte macro option.
736 Telnet SUPDUP option.
748 Telnet randomly-lose option.
749 Telnet SUPDUP-Output option.
779 Telnet send-location option.
855 Telnet Option Specifications.
857 Telnet Echo Option.
858 Telnet Suppress Go Ahead Option.
859 Telnet Status Option.
860 Telnet Timing Mark Option.
861 Telnet Extended Options: List Option.
884 Telnet terminal type option.
885 Telnet end of record option.
927 TACACS user identification Telnet option.
930 Telnet terminal type option.
933 Output marking Telnet option.
946 Telnet terminal location number option.
1041 Telnet 3270 regime option.
1043 Telnet Data Entry Terminal option: DODIIS implementation.
1053 Telnet X.3 PAD option.
1073 Telnet window size option.
1079 Telnet terminal speed option.
1080 Telnet remote flow control option.
1091 Telnet terminal-type option.
1096 Telnet X display location option.
1097 Telnet subliminal-message option.
1116 Telnet Linemode option.
1143 The Q Method of Implementing TELNET Option Negotiation.
1184 Telnet Linemode Option.
1372 Telnet Remote Flow Control Option.
1408 Telnet Environment Option.
1409 Telnet Authentication Option.
1416 Telnet Authentication Option.
1571 Telnet Environment Option Interoperability Issues.
1572 Telnet Environment Option.
2066 TELNET CHARSET Option.
2217 Telnet Com Port Control Option.
2840 TELNET KERMIT OPTION.
2941 Telnet Authentication Option.
2946 Telnet Data Encryption Option.
then jump to RFC 1123, Section 3, and check your conformance with
all the MUST/SHOULD/MAY/SHOULD_NOT/MUST_NOT requirements [just under
50 of them, funny coincidence]. And then if you're *really* trying
to play nice, see if your IP implementation (yes, IP, *two* layers
down from Telnet!) is willing to set the Telnet Type-of-Service Value
in each IP packet of the TCP connection carrying your Telnet session
[RFCs 1060 & 1349].
Then figure out how you're going to support it now that you've
implemented this steaming pile! ;-} ;-}
-Rob [who once wrote a "tn3270d" server for a
Unix that was running on top of VM/370...]
p.s. O.k., o.k., you can safely ignore RFCs 748 & 1097. But at least
read them first... ;-} ;-}
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> People here on comp.lang.lisp somtimes complain that the Common Lisp
> pathname mechanism was designed to accomodate the vagaries of
> "strange operating systems that nobody uses anymore". Hah! You
> ain't seen *nuttin'* in the way of supporting "strange operating
> systems" 'til you try to do a complete implementation of Telnet!
And when you're done with Telnet, try FTP for even more fun!
Well, at least most FTP clients do fine when you signal a "not
implemented" for most of the unneeded commands; OTOH those clients
think that the "LIST <pathname>\r\n" command apparently means that
they should send "LIST -a <pathname>\r\n".
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
····@rpw3.org (Rob Warnock) writes:
> p.s. O.k., o.k., you can safely ignore RFCs 748 & 1097. But at least
> read them first... ;-} ;-}
Their option codes don't fit in 8 bits. Is it possible to encode
them with the RFC 698 Telnet extended ASCII option, or do they
require a 9-bit-clean TCP/IP stack?
Kalle Olavi Niemitalo <···@iki.fi> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
|
| > p.s. O.k., o.k., you can safely ignore RFCs 748 & 1097. But at least
| > read them first... ;-} ;-}
|
| Their option codes don't fit in 8 bits. Is it possible to encode
| them with the RFC 698 Telnet extended ASCII option, or do they
| require a 9-bit-clean TCP/IP stack?
+---------------
What, you don't have one? ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Sun, 17 Jul 2005 05:17:29 -0500, <····@rpw3.org> wrote:
>
>
> GP lisper <········@clouddancer.com> wrote:
> +---------------
>| Finger or Whois are essentially a single connection, squirt some info
>| down the pipe and disconnect. A hard part of telnetd is serving
>| multiple connections.
> +---------------
>
> Sorry to contradict, but that's the *easy* part!
Yes, but multiple connections is a 'hard part' in lisp. Apparently,
only threaded lisps can work. That's interesting, since telnetd was
part of linux long before threading appeared.
Actually, what I really need is probably closer to a streaming server.
Consider a server which sends a large file (takes hours) to any remote
process that connects to it's server port. To me, that appears as a
broadcast-stream process that needs some way of updating the
broadcast-stream member list without breaking any connections. It
seemed that a telnetd server might contain some useful code that I
could extract. There is no requirement to send from the start of file
for any new connecting process.
I'm working thru the macros behind make-broadcast-stream at the
moment.
--
[ingvar] Modelling forest damage by storms with regular expressions is...
a curious idea.
[Xach] before: ||| after: //_
[Xach] seems easy enough to me
GP lisper wrote:
> Yes, but multiple connections is a 'hard part' in lisp. Apparently,
> only threaded lisps can work. That's interesting, since telnetd was
> part of linux long before threading appeared.
I think in Linux for every incoming connection a new process is started, so
no threading support needed. But you can always implement it with one
thread, if you use "select" (see the unix man page of this C function). Of
course, not in pure Common Lisp, because it has no network support.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Mon, 18 Jul 2005 00:43:01 -0700, GP lisper <········@CloudDancer.com> wrote:
> Yes, but multiple connections is a 'hard part' in lisp. Apparently,
> only threaded lisps can work.
Not necessarily.
<http://common-lisp.net/project/cmucl/doc/cmu-user/serve-event.html>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 18 Jul 2005 10:22:00 +0200, <········@agharta.de> wrote:
>
> On Mon, 18 Jul 2005 00:43:01 -0700, GP lisper <········@CloudDancer.com> wrote:
>
>> Yes, but multiple connections is a 'hard part' in lisp. Apparently,
>> only threaded lisps can work.
>
> Not necessarily.
>
> <http://common-lisp.net/project/cmucl/doc/cmu-user/serve-event.html>
Thanks for that link Edi, it could solve my requirement.
--
[ingvar] Modelling forest damage by storms with regular expressions is...
a curious idea.
[Xach] before: ||| after: //_
[Xach] seems easy enough to me
GP lisper <········@CloudDancer.com> writes:
> Yes, but multiple connections is a 'hard part' in lisp. Apparently,
> only threaded lisps can work. That's interesting, since telnetd was
> part of linux long before threading appeared.
Think processes, not threads.
--
Espen Wiborg <·······@grumblesmurf.org>
An ostrich's eye is bigger than its brain.
GP lisper <········@CloudDancer.com> writes:
> Yes, but multiple connections is a 'hard part' in lisp. Apparently,
> only threaded lisps can work. That's interesting, since telnetd was
> part of linux long before threading appeared.
"If people understood fork, we wouldn't have threads."
-- Rob Pike.
> Actually, what I really need is probably closer to a streaming server.
> Consider a server which sends a large file (takes hours) to any remote
> process that connects to it's server port. To me, that appears as a
> broadcast-stream process that needs some way of updating the
> broadcast-stream member list without breaking any connections.
The nice thing about having an operating system is that
you don't need to reinvent it in your programming language's
runtime system.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> GP lisper <········@CloudDancer.com> writes:
> > Yes, but multiple connections is a 'hard part' in lisp. Apparently,
> > only threaded lisps can work. That's interesting, since telnetd was
> > part of linux long before threading appeared.
>
> "If people understood fork, we wouldn't have threads."
> -- Rob Pike.
To implement telnet correctly for one connection requires multiprocessing.
Christopher C. Stacy <······@news.dtpq.com> wrote:
+---------------
| Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
| > GP lisper <········@CloudDancer.com> writes:
| > > Yes, but multiple connections is a 'hard part' in lisp. Apparently,
| > > only threaded lisps can work. That's interesting, since telnetd was
| > > part of linux long before threading appeared.
| >
| > "If people understood fork, we wouldn't have threads."
| > -- Rob Pike.
|
| To implement telnet correctly for one connection requires multiprocessing.
+---------------
Not so, if you have a reliable "select()" and non-blocking I/O.
In that case, a single process can easily do *multiple* telnetd's.
This is within-one-process multiprogramming, not multiprocessing.
Aside#1: What CMUCL call's "multiprocessing" is no such thing. It's really
within-one-process multiprogramming, a.k.a. "cooperative green threads".]
Aside: I don't know if CMUCL's SERVE-EVENT is adequate to handle
the "telnetd" job, but it might be.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
GP lisper <········@CloudDancer.com> writes:
> Funny, most text-based Muds are telnet based. Why did your friend
> kill your idea?
Because of the likes of Neverwinter Nights, WoW, etc. Also he said
the infrastructure requirements (network bandwidth, etc) would kill
me. With all the other things I also want to do, this left the idea
kind of dead.
> Finger or Whois are essentially a single connection, squirt some info
> down the pipe and disconnect. A hard part of telnetd is serving
> multiple connections.
After Zach's response, I'll retract my claim on the ease of telnet
until such time I have working code to back me up.
I did a bit of HTTP as well in Java, but not a complete implementation
of the 1.1 spec.
--
My .sig file sucks. Can anyone recommend a better one?
On 18 Jul 2005 11:25:24 -0400, <·····@david-steuber.com> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>> Funny, most text-based Muds are telnet based. Why did your friend
>> kill your idea?
>
> Because of the likes of Neverwinter Nights, WoW, etc. Also he said
> the infrastructure requirements (network bandwidth, etc) would kill
> me. With all the other things I also want to do, this left the idea
> kind of dead.
Despite NWN or WoW or any of the GUI MUDs, many telnet MUDs continue
to exist. They are small scale experiments, thus have little network
bandwidth required. There are many problems in Multi-User Dungeons
that should be solved at the text level, then rolled into the GUIs.
If network bandwidth got to the 'killing stage', time to visit the
bank. This is probably what Paul Graham means with comments such as
Wall Street Journal is filled with "ideas", he sees problems such as
killing network bandwidth as an opportunity.
P.S. if you MUD idea involved a much better monster A.I. attack, I'd
go back to it if I was you. Predictable monsters doom games.
--
[ingvar] Modelling forest damage by storms with regular expressions is...
a curious idea.
[Xach] before: ||| after: //_
[Xach] seems easy enough to me
GP lisper <········@CloudDancer.com> writes:
> On 18 Jul 2005 11:25:24 -0400, <·····@david-steuber.com> wrote:
>> GP lisper <········@CloudDancer.com> writes:
>>
>>> Funny, most text-based Muds are telnet based. Why did your friend
>>> kill your idea?
>>
>> Because of the likes of Neverwinter Nights, WoW, etc. Also he said
>> the infrastructure requirements (network bandwidth, etc) would kill
>> me. With all the other things I also want to do, this left the idea
>> kind of dead.
>
> Despite NWN or WoW or any of the GUI MUDs, many telnet MUDs continue
> to exist. They are small scale experiments, thus have little network
> bandwidth required. There are many problems in Multi-User Dungeons
> that should be solved at the text level, then rolled into the GUIs.
There are a lot of text-based MUDs that are considerably beyond the
"small scale experiment" stage, several of them even commercial
(e.g. GemStone, Castle Marrach, DragonRealms). It's a niche market,
so you won't get World of Warcraft-scale subscription numbers, but
there are people willing to pay to play. And they're a lot cheaper to
develop and run than the graphical monsters.