apam wrote to All on 05-25-18 14:04 <=-
Hey
Last night I got FTN<->Mnet working meaning there are now 2 happynets
one on FTN and one on MNET and the one happynet area is shared between
the two.
Kind of like WWIVnet-FTN.
Anyway, what's the point? Apart from experimenting, and learning about challenges with coming up with a network, not much really.
So where to from here?
I think there needs to be a better transport than binkd, something that checks a mail is actually from who it says it's from (otherwise someone could craft packets to unsub/sub other systems to areas).
Is it worth pursuing though? I don't know.
I think there needs to be a better transport than binkd, somethin checks a mail is actually from who it says it's from (otherwise s could craft packets to unsub/sub other systems to areas).
Is it worth pursuing though? I don't know.
That's why binkd has session passwords and your tosser should have
packet passwords.
apam wrote to Bill McGarrity on 05-25-18 21:28 <=-
I think there needs to be a better transport than binkd, somethin checks a mail is actually from who it says it's from (otherwise s could craft packets to unsub/sub other systems to areas).
Is it worth pursuing though? I don't know.
That's why binkd has session passwords and your tosser should have
packet passwords.
Yes, but I'm not talking about improving binkd for use with FTN, it already works well. I'm referring to my network needing a different
kind of transport rather than using binkd (which binkd isn't designed for).
Quoting apam to All <=-
Is it worth pursuing though? I don't know.
Quoting apam to All <=-
Is it worth pursuing though? I don't know.
Yes it's worth pursuing, but I'm going to make a suggestion. Start
early
to make it something that can work with ANY package. That's why
FTN was
always the "market leader" it was done external of most packages.
Yes, but I'm not talking about improving binkd for use with FTN, already works well. I'm referring to my network needing a differe
kind of transport rather than using binkd (which binkd isn't desi for).
Ahhh.. ok. Why not use FTP then?
Yes it's worth pursuing, but I'm going to make a suggestion. Start early to make it something that can work with ANY package. That's why
That's kind of what I did with the mystic utilities, but it works with
Yes, but I'm not talking about improving binkd for use with FTN, already works well. I'm referring to my network needing a differe kind of transport rather than using binkd (which binkd isn't desi for).
Ahhh.. ok. Why not use FTP then?
I did actually think about using FTP, and it would work, but I'm not sure how to set it up. It would need a login for each node, and r/w access to each node's out directory, and the client would need to delete the file from the server after downloading.
On 05/26/18, apam pondered and said...
That's kind of what I did with the mystic utilities, but it works
Sorry which Mystic utils are these you speak of? Just confused :)
Oh, I wrote a scanner / tosser for my system that works on mystic (or
any JAM based message base I think). I've not kept it up to date as
I've been improving the system though.
Hmm, then there is the possibility of nodes deleting other peoples
packets in the inbound directory, as they would need write access to upload their own packets.
apam wrote to Bill McGarrity on 05-26-18 10:06 <=-
Yes, but I'm not talking about improving binkd for use with FTN, already works well. I'm referring to my network needing a differe
kind of transport rather than using binkd (which binkd isn't desi for).
Ahhh.. ok. Why not use FTP then?
I did actually think about using FTP, and it would work, but I'm not
sure how to set it up. It would need a login for each node, and r/w
access to each node's out directory, and the client would need to
delete the file from the server after downloading.
I guess the seperate logins would be easy enough, as well as seperate permissions, I'm just not sure how to script the client to delete files after downloading it.
Hmm, then there is the possibility of nodes deleting other peoples
packets in the inbound directory, as they would need write access to upload their own packets.
I'll have to think about it some more.. thanks for the suggestion!
All you'd have to do is structure it off of a QWK style network. FTP connection made, login performed, an upload of a REP pkt and then
download of a QWK pkt. Naturally, scanning of the message base would
be necessary for each call. Synchronet uses QNET-FTP.bin (baja file)
to perform this task.
apam wrote to Bill McGarrity on 05-26-18 23:19 <=-
I've got something working now, I wrote a special ftp server and client and it seems to do exactly what I hoped.. only being ftp it's not encrypted, so that's a challenge for another day :)
I've got something working now, I wrote a special ftp server and client and it seems to do exactly what I hoped.. only being ftp it's not encrypted, so that's a challenge for another day :)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 69:47:44 |
| Calls: | 6,655 |
| Calls today: | 1 |
| Files: | 12,200 |
| Messages: | 5,332,101 |
| Posted today: | 1 |