QSEND server and client

[larsbrinkhoff]

Add server and client for the QSEND protocol.

I envision the server side to call out to a user-supplied shell script or program that can be customized to handle the message delivery.

One use case I have in mind, is for ITS to send a message to a particular destination that will be displayed as a desktop notification.

[larsbrinkhoff]

Even though the user interface and protocol is usually referred to as QSEND, the Chaosnet contact name is just SEND.

It seems the first line in the packet should be SEND USER[@MACHINE]. The machine part is optional, and left out means local delivery. I'm not sure whether an atsign means to forward the message.

The rest of the data is probably the messsage body. Maybe there can be a header line first, or several lines? Or maybe it's a free-format, anything goes kind of thing.

@ams, @bictorv What do you figure a Lispm expects in a Chaosnet (Q)SEND transaction?

[larsbrinkhoff]

It seems the Lispm character set should be used, so e.g. line endings are 215.

[larsbrinkhoff]

Revised understanding is that the RFC packet only carries the destination USER@HOST, not any message content. The content probably arrives in regular DAT packet(s), followed by a CLS.

[larsbrinkhoff]

CC @eswenson1 FYI

[larsbrinkhoff]

I have now successfully sent a message from the host into ITS; that's the client part.

[larsbrinkhoff]

Also received messages from ITS.

The ITS send command supplies a single header line before the message body: "user@host time". For example, LARS@KA 2:33pm Maybe this is part of the protocol, or maybe it's a convention.

[bictorv]

You should test this with a LISPM too?

[larsbrinkhoff]

Someone should test, yes, but apparently there are no free Lispms. @ams, @eswenson1 do you have any?

[bictorv]

Try CDR?

[eswenson1]

Ejs-lispm-4 (5472) should be up. Unless, of course either chaos.swenson.org (5401) or chaos3.swenson.org) (5403) — both running cbridge — died again.

[bictorv]

I realized this is about a new branch of this repo, and tried it. Quick reactions after trying it with CDR:

• the provided qsend-incoming script isn't very useful, since it doesn't show the incoming message?
• the message sent by qsend doesn't seem to include the sender?

But it seems promising! :-)

[larsbrinkhoff]

Right, it's a branch rather than a pull request because it's a work in progress. Moreover, I don't really know the details of the protocol because it's not documented. Is there anything enlightening in e.g. Lispm source code?

qsend-incoming isn't finished; I just started drafting it now. It should do something reasonable, but be available for customization.

Should the message sent by qsend include the sender? I don't know. Does anyone know? Is it required by the protocol? Is there a defined protocol? Does any server rely on the first line in the message being something in particular?

[larsbrinkhoff]

Note for testers: for outgoing sends you have to set SNDFLG in HACTRN to -1 for DDT to call the SENDER program, which knows how to use Chaosnet.

[eswenson1]

Isn't that only if you want to use :SEND rather than :QSEND? Setting SNDFLG makes DDT use the external SEND/QSEND program, rather than the built-in DDT SEND, which doesn't know how to do QSEND.

However, setting SNDFLG is really a good idea in any case, because if you are using plain-old (local) :SEND, and the recipient is not logged in, you can convert the message to MAIL and send it that way.

[eswenson1]

Ejs-lispm-4 (5472) should be up. Unless, of course either chaos.swenson.org (5401) or chaos3.swenson.org) (5403) — both running cbridge — died again.

Well, it would appear that ejs-lispm-4, running a pre-released of System 302, is not capable of receiving QSENDs. I'm not sure why. In any case, ejs-lispm-1 (5467) is also running and qsend works fine with it (from/to ITS).

I did try to use the qsend client from Lars' branch to send to eswenson@ejs-lispm-1 and no message was ever received. I was able to use the qsend client to send a message to "ejs@es", however.

I am able to QSEND to eswenson@ejs-lispm-1 from ES, so I don't know why Lars' qsend client can't -- since it can send to ITS.

[larsbrinkhoff]

As far as I can see, DDT runs SEND (built from SENDER), not QSEND (built from QMAIL).

Maybe the lispm server expects the message body to be formatted some particular way, in particular the first line. ITS doesn't care. Can you send from a lispm to my senver server? I have updated it just now and made the qsend-incoming script more useful. If so, I would be interested in the output from the script.

Note that qsend-incoming must be found on the PATH; either make PATH include the chaosnet-tools source directory, or set the QSEND environment variable to point to the full path of qsend-incoming.

[eswenson1]

As far as I can see, DDT runs SEND (built from SENDER), not QSEND (built from QMAIL).

Yes, that is correct. It will only "run" QSEND if you have a link in an NFDIR or your home directory from TS SEND to TS QSEND.

Maybe the lispm server expects the message body to be formatted some particular way, in particular the first line. ITS doesn't care.

Can you send from a lispm to my senver server?

No.

I have updated it just now and made the qsend-incoming script more useful. If so, I would be interested in the output from the script.

Yes, I have that change. I had to add my chaosnet-tools directory to my path in order for senver to find qsend-incoming (you should make it default to the same directory as senver).

I'm able to send from CHAOS3 to ES and from ES to CHAOS3 (where CHAOS3 is my bridge). But in neither direction to/from ejs-lispm-1.

Note that qsend-incoming must be found on the PATH; either make PATH include the chaosnet-tools source directory, or set the QSEND environment variable to point to the full path of qsend-incoming. See above.

[larsbrinkhoff]

@ams wrote:

Why it doesn’t work is probobly cause ejs didn’t load CONVERSE.

[eswenson1]

I did load converse. And I was able to send messages to ejs-lispm-4 from ES and ejs-lispm-1 and have them received. Just not messages from the qsend binary in chaosnet-tools. Same for the other direction.

[ams]

@eswenson1 does #148 works ? Eg if you load the QFASL in "301", and then try it?

I updated CONVERSE recently so if it worked and doesn't now it is some change from 130 that breaks things .. maybe QSEND was removed and just SEND is used? Is there a difference?

[ams]

pre-released of System 302

System "301"...

[ams]

It might be that you need to explicitly enable Converse receiving .. I seem to recall such a change.

[eswenson1]

That doesn't explain why I can't send from ejs-lispm-4 (301+) to ES or ejs-lispm-1.

[larsbrinkhoff]

maybe QSEND was removed and just SEND is used? Is there a difference?

It's awkward, because it's often called QSEND, but really there is only SEND. Or so I think. ITS has both TS SEND and TS QSEND clients, and they both use the SEND contact name. ITS has two servers, also using the SEND contact. So as far as I can see SEND and QSEND are one and the same, just two names for the same thing. Maybe it's the Q prefix for Lispm things, like QFASL is a Lispm FASL?

[larsbrinkhoff]

I had to add my chaosnet-tools directory to my path in order for senver to find qsend-incoming (you should make it default to the same directory as senver).

It's not running from the senver directory by design. It's the kind of thing a malicious agent could exploit. It's the users's responsibility to either 1. put the program in one of the PATH directories, or 2. update PATH, or 3. set QSEND to point out the program. In fact, maybe QSEND should be the only way.

[ams]

@eswenson1 If you hack uch11-udp.c in usim, specifically chaos_send_to_udp(), so that it does dumpmem(buffer,size); you can get the raw packets that are being sent and compare them to whatever ITS might expect.

[larsbrinkhoff]

It's not what ITS expects. It accepts anything as far as message contents go. It's what the Lispm expects. We don't know if it's the message format that is off, or what, but it's something to check.

[larsbrinkhoff]

I do see in converse.lisp it's looking for user@ or "from user" in the first line, but lack thereof doesn't cause the message to be discarded.

[bictorv]

I do see in converse.lisp it's looking for user@ or "from user" in the first line, but lack thereof doesn't cause the message to be discarded.

If SEND wouldn't provide the sender's ID, there would be no way to send a reply to the user who sent it - thus no way to CONVERSE.

To see the LISPM receiver code, check RECEIVE-MSG in sys/io1/conver.lisp (or CHAOS-RECEIVE-CONVERSE-MESSAGE in the same file in more recent code - search for "SEND and you'll find it.

To see the sender code, check SEND-MSG in the same file as RECEIVE-MSG (or (NET:SEND-TERMINAL-MESSAGE :CHAOS) in sys/network/chaos/chsaux.lisp in more recent versions of the code).

[bictorv]

@eswenson1 If you hack uch11-udp.c in usim, specifically chaos_send_to_udp(), so that it does dumpmem(buffer,size); you can get the raw packets that are being sent and compare them to whatever ITS might expect.

Or if you simply use Wireshark/tshark you don't need to hack the source?

[bictorv]

Can you send from a lispm to my senver server?

No.

I can, running System 300. But senver (the most recent version) doesn't show who the message is from, and in Converse, messages from qsend show contents above recipient.

[ams]

I'm rebuilding System right now so sorta can't debug it. But it would be useful to know if just loading the old version vs. the new version @bictorv Can you QC the latest CONVERSE and check? I can upload a QFASL if it makes it easier.

[larsbrinkhoff]

But senver (the most recent version) doesn't show who the message is from

I believe my senver displays everything from the RFC packet, and everything in the subsequent DAT packet(s). I don't think I can do much more. If the Lispm somehow sends/receives something more, I'm curious how.

I did read CONVERSE-RECEIVE-MSG. It parses out some data from the first DAT line. My senver just prints out the first line along with the rest of the message.

[eswenson1]

From my LM4, with converse loaded, doing a (qsend "ejs@chaos3" "foo") returns NIL and nothing shows up on my terminal running senver. I have the last lars/qsend branch code, freshly built. I do have cbrige (chaos3) running. And LM4 sees CHAOS3 (5403) ES, and EX (latter two connected to CHAOS (5401)). CHAOS3 connects to CHAOS via TLS. CHAOS connects to global chaosnet via TLS.

Doing a (qsend "ejs@es" "foo") returns ("ejs@es") and I see the message on ES.

And going a :qsend eswenson@ejs-lispm-4 foo from ES, I see the message appear on EJS-LISPM-4.

Doing a :qsend ejs@chaos3 from ES shows me the message in SENVER, so from ITS -> SENVER, works fine.

So it appears to be an issue with SENVER and LISPM.