ARexx msgs. via DNet
15 messages in this thread
I have been looking for any program that will allow the creation and
transmission of ARexx ports/messages across Dnet between two machines.
If you have a lead on such a beast, please drop me a line.
– Chris 70431,2172
Try vlt.
– Richard
"Try vlt."
I don't understand.. Can VLT take advantage of DNet?
I'm not really very familiar with DNet, so I couldn't answer you there.
It may be that it can take advantage of DNet. I gleaned from your comments
that you were interested in sending ARexx commands from one Amiga to
another. VLT does this without DNet. It uses fifo pipes and supports ARexx.
You can address the CLI on a remote Amiga. It's a free program and you can
write to SLAC for a free manual that includes the details on setting this
up.
– Richard
Thanks for the information. This sounds like a good lead.
Christopher,
I didn't answer this when I first read it, because I figured that DNet
was the important part of the question. Your answer to Richard makes me
think that the important part is just getting an Arexx message to the other
machine.
If this is the case, I would recommend you take a look at ROBBS, which
stands for Rexx Object Building Block System. In particular, SerMod is a
serial port program that is controllable from ARexx, and allows any ARexx
program to communicate via the serial port. It will match strings (10
strings may be armed at a time), send data, route incoming data, and more.
It's here in the LIBs (Arexx programming, I think), as SERMOD.LZH. Check
for it by using 'BRO KEY:ROBBS LIB:ALL'. This will get you to both SerMod
and DispMod. DispMod may not be necessary for your application, but then
again, it could be handy for such things as checking status, manual control
of remote machine, etc.
-larry
Actually, DNet is/was the important part, although I am open to
alternatives. It would depend on how securely VLT could xmit data from an
ARexx port. I *am* looking for a good way to implement packet-switching on
a BBS, with the most dramatic benefit being able to take advantage of most
modems' full-duplex communication channel, allowing simultaneous text,
upload and download at nearly full speed. Traditional terminal/BBS
intersctions have either limited what a user can take an interest in during
their usual sessions, or kept their phonebills substantilly higher than
they've had to be.
I want to see this change.
Chris,
Could you elaborate on the setup? One modem? Two machines sharing duties?
Sounds like an interesting project.
-larry
Being a local SysOp, what I had in mind was a vehicle for allowing
full-duplex, multi-channel communications between a BBS and a users'
terminal. This can be done with a single modem and serial port on each
side of the connection.
I have considered many alternative ways to implement this,
including: Writing a stand-in for serial.device (similar to serial
devices for add-on serial boards) that sends/receives I/O through a
DNet channel which in turn multiplexes the data stream through an
actual serial.device; writing a relatively simple program to provide
access to Dnet through a simple PIPE:-like device (not sure this
would work due to the nature of DOS i/o); etc.
I like the former idea best, as you could easily put almost any BBS
program online with DNet this way. Once the BBS's ASCII/menu/message
system is accesable via Dnet, simply define the 'putfiles' and
'getfiles' client programs (supplied with DNet) as custom file
transfer protocols within your specific BBS program. When
putfiles/getfiles are RUN, the BBS menu system resumes normal
operation immediately while the file transfers tick away.
Unless you have a specific need to access files on a separate Amiga,
I don't really ee the need for DNet. A single program, connected to
the serial.device, could identify and dispatch packets to appropriate
tasks, and collect packets for transmission to the modem.
I have considered that approach, and have avoided it for the following
reasons:
1) Existing BBS software would not be able to run with this arrangement.
Custom message/file bases (and probably custom file transfer programs) will
have to be written.
2) I'd have to come up with my own algolrythym for full-duplex
packet-switching, including windowing (send-ahead) and verification of
proper reception by the other end. This is what DNet does so well; I do not
want to exert such great effort to re-invent the wheel.
Also, it should be understood that DNet in itself is not a network
filesystem (which is the impression I think you have, from what I can see
from your last message), but simply a packet-switching protocol that can
provide many virtual I/O connections over a single hardware I/O connection
between two machines. In addition to this, many people use the 'NET'
filesystem for DNet written by the Software Distillery to share devices
between CPUs; I am, however, only interested in the DNet portion to provide
'packet dispatching' in just the way you described.
I have obtained a version of the DNet include library from some Software
Distillery source code that compiles relatively easily, so I can access
DNet. But now I've got to 'bridge the gap' between DNet and existing BBS
software, or something, for even if I were to write my own interactive
message base system, programming in 'C' is my idea of hell on earth, and
would rather stick to languages like ARexx, Modula, or even BASIC.
Chris,
There is a dnet.device that works with VLT. Use it in place of the
serial.device. (Select it via the "Comm/Select Device" menu item.) I've
only used it once, to verify that it worked, but it may be what you're
looking for. Dnet.device is in the v2.20 distribution of DNet. It's
available from ftp.uu.net. If I remember right, it's in the directory
"/systems/amiga/dillon". You'll need the files dnet.lzh and
dnet_missing.lzh. I'm not sure that this version is available on CIS.
Drop me a note if it isn't, and I'll upload it.
–dds (dales@teksce.SCE.TEK.COM)
Whappeta-whappeta-Whap!
Now THAT is news <g>! I ahven't seen anything later than V.2.13 of DNet,
and that is, as far as I can tell, defunct.
Since I am not mired in the ways of usenet, I would be grateful if you
would upload the V2.20 package here (or another accessable 'location' such
as the Software Distillery BBS (919)-460-7430).
I don't have or know what dnet_missing.lzh is, and I don't know if my
current version of DNet (V2.10) would work with dnet.device, so I'd
appreciate it if you could upload the complete package; From what
experience I've had w/Dillon-ware so far, I'm sure there are LOTS of small
details that could get in the way me accomplishing what I would like to if
even the tiniest little piece is omitted.
Thanks again,
– Chris
First, my apologies for not replying to your e-plex; ye olde flu
bug had me down for a few days. I'll merge the the relevant archives
into one, and upload it here as soon as I can.
"From what experience I've had w/Dillon-ware so far, I'm sure there
are LOTS of small details that could get in the way me accomplishing
what I would like to if even the tiniest little piece is omitted."
Heh, yeah, you're right. 🙂 Still, once you get it going,
DNet is great! I've had multiple shell windows going, along with an
up- and down-load running, all simultaneously. At 2400 bps, the
response time is pretty slow, and painting the screen is pretty
jerky, but it *does* work. I find that reading Usenet News is okay
with everything running like that, but trying to edit a file is — ah
-painful. Deathly slow, is more like it. However, without the file
transfers, editing works pretty well, even at 2400 bps, and multiple
shells are no trouble at all. (I'm on pins and needles waiting for
my v.32bis modem to arrive. *That* ought to take care of the packet
delays!)
The parts that people seem to have trouble with are getting the
dnet.servers files correct, getting the parity and protocol handling
settings correct, and getting the Unix end of the program to compile.
DNet only compiles under BSD, or a close clone (e.g., SunOS). I
don't know of anybody who's gotten it to compile and run under any
flavor of System V. (If anybody out there has done so, *PLEASE* let
me know!)
BTW, v2.13 isn't really defunct. In fact, the 2.13 Amiga
binaries are what I'm running right now. Matt pulled some boners
when he assembled the v2.20 archive, and he got the wrong binaries
installed for the Amiga side. It's been working well enough for me
that I've not been motivated to try and re-compile them.
Oh well, I've rambled on enough. Time to Whap! the Forums and
Libraries…
Dale,
Thanks for your insightful reply. I feel I am making progress, as I slowly
pick up clues and pointers. Still, I am primarily concerned with a purely
Amiga<->Amiga connection, and for almost none of the reasons usually
associated with DNet (NET: filesystems, remote CLIs, Unix). Strangely,
using DNet for a BBS would benefit far more people than its current uses
would.
I noticed the support library you uploaded seperately; This should be
instrumental in revising and recompiling existing DNet programs via SAS/C.
I have actually already compiled my own little DNet server using a mutant
dnetlib that I found with the Software Distillery's NETKEYS package; This
function library requires no other special files to compile.
RE: getting 2.20 protocol to start..
I had found one of the 'incomplete' 2.20 archives on Smorgasboard BBS and
set it up on my two Amigas (the same systems I use to test my current DNet
project) by dropping the new binaries into the existing setup, and it seems
to behave as 2.13 did: Select 'Start Protocol' on one end, and the other
end displays a few garbage characters and does nothing. I am using a Radio
Shack null modem adaptor and Dataspec full 25-pin serial cable for the
connection.. I've tried every relevant parameter in starting DNet I could
find including 7-wire, Xon/Xoff, 8-bit path, carrier-detect disable,
lowering baud-rates, ad infinitum. I haven't tried the archive you uploaded
yet, but will do so shortly.
As for experimenting with the dnet.device(s), I have discovered that
terminals are much less demanding of the serial.device than BBSs are; The
BBS software I presently run, Citadel, opens/closes the device no less than
3 times in rapid succession when it is first executed. Other BBSs I'm
trying either don't work at all even with serial.device or won't allow the
device/unit# to be changed.
I am open to suggestions on good BBS software (esp. w/ a strong/nice
message base)!
Regards,
Chris (who also eagerly awaits his v.32bis modem <g>)
[ MORE ]