Is there any reason not to archive netmail?
To make sure the destination will process it?That is the truth in my my case at least, uncompressed netmails will
be processed.
There is no content to transfer. You don't need a road if nobody
travels.
Your actual scenario is two machines that have a road that is used for nothing more that to prove "look, there is a road".
Do one step back and get aware that insecure compressed ping creates problems for no reason other than to have a problem to be solved.
Now the cat is out of the bag. You really do want to change the
default behavior of the whole fidonet for insecure compressed mail.
I agree with you that nodes should always send netmail
uncompressed
Then please follow this path. It is the solution with no issues.
Be a good coordinator and teach selfish nodes why to turn off
compression for insecure netmail. Do not support their annoying
behavior by working around.
You are going to force the whole fidonet to support compression.
You can do what ever you will on your system but stop forcing me/us to support compression. You don't know what is running on "our" side.
There is no arc support for the Pandora, for example. http://repo.openpandora.org/?page=all&search=unarc
What will be then? Would you simply say i'm no longer part of fidonet
if i can't support compression?
Or will you invent a "noarc" flag for the nodelist that any node does
know that i do not support compression?
You intention for easy going with compressed insecure mail will
backfire then because you have to install the "unarc" flag condition
to the whole fidonet systems including yours. See the top of this
mail, you're creating issues where are none.
I find no policy or FTN standard that directs nodes not to do
that and that is why it happens.
I showed you two times already. The *transfer*! format is defined by FTS-0001.
Compression after agreement is defined by the echopol and that is a freedom i'd like to see for the whole fidonet. You can use any
compression tool you like if both parties agree.
If one does not agree or the parties never talked about compression
before then no compression is the solution that will work on the whole fidonet.
Is there any reason not to archive netmail? Some tossers I have
used did that and some didn't. No reason to archive it or not
that I know of.
Is there any reason to compress netmail prior to sending nowdays?
I don't see one, and i'm a bandwith-saving-guy.
Do you allow me to try to fill your disk?
On ethical basis with prior notice of course.
Feel free to enjoy the ride...
Do you allow me to try to fill your disk?Say, your not that bastard operator from hell that Kai warned me about
are you? ;)
On ethical basis with prior notice of course.Are those my ethics, or yours.
I don't compress netmail. The issue I am seeing happens when I receive netmail that is compressed in my insecure inbound. The arcmail bundle
sits there until I decompress it.
I don't see one, and i'm a bandwith-saving-guy.I am too. Not that it matters much but I don't like to waste.
No, i'm not. I'm one of the defense guys, but i need to know
where the holes are to be able to fill them ... by fixing it.
That's a thing we'd agree on. I'd never attack a system without
consent of the target sysop. Back in the days, we had the
agreement to prepare everyting and then get the sysop on
a voice line. Then we agreed again and started. That was a very
tiny group of people here in switzerland doing this, 3 in fact.
I am too. Not that it matters much but I don't like to waste.
Yep, Bink does a fine job on compressing. So we all can be happy.
100% agree. Echomail historically was sent compressed. You know, cost savings in POTS. Nowdays, echomail is no longer compressed prior
to sending as BinkD does a good job ab it anyway. That reduces
tosser processing times.
When i re-started my fidonet operations, i was a fan of compressing outbound echomails but got convinced after a few tests and some statistics, that compressing with the tosser/packer is no longer
needed.
In fact, i no longer have any of my links/feeds running with
packed echomails. TBH, i've even disabled the unpacking feature
at all, even in secure inbound.
I've agreed with all my links/feeds, that we deliver eachother uncompressed and that's it.
I've agreed with all my links/feeds, that we deliver eachother
uncompressed and that's it.
I sometimes turn on compression for links that are offline for a bit longer then 1 or 2 days. Because with the high frequent tossing that happens today, the outbound directories quickly fill up with hundreds
of .pkt files, which I don't like. With compression turned on there
are at most 7 files for each (offline) node waiting to be send. When
they become connectable again I turn compression back off...
I sometimes turn on compression for links that are offline for a bit
longer then 1 or 2 days. Because with the high frequent tossing that
happens today, the outbound directories quickly fill up with hundreds
of .pkt files, which I don't like. With compression turned on there
are at most 7 files for each (offline) node waiting to be send. When
they become connectable again I turn compression back off...
That's a nice idea, but forces manual intervention in most cases.
Packed echomail is a bad idea with the high frequenies as one will
run out of file extensions after 36 polls. (.WE0-9 + .WEA-Z).
Having unpacked for offline systems is a pain in the outbound, but
having compressed for active nodes is a pain as well.
My solution: uncompressed & not looking in the outbound too often.
Packed echomail is a bad idea with the high frequenies as one
will run out of file extensions after 36 polls. (.WE0-9 +
.WEA-Z).
It could indeed. My tosser just keeps using the Z if that's reached.
Which doesn't seem to cause problems, as far as I'm aware of...
I sometimes turn on compression for links that are offline for a bit longer then 1 or 2 days. Because with the high frequent tossing that happens today, the outbound directories quickly fill up with hundreds of pkt files, which I don't like. With compression turned on there are at most 7 files for each (offline) node waiting to be send. When they become connectable again I turn compression back off...
I sometimes turn on compression for links that are offline for a
bit longer then 1 or 2 days. Because with the high frequent
tossing that happens today, the outbound directories quickly
fill up with hundreds of pkt files, which I don't like. With
compression turned on there are at most 7 files for each
(offline) node waiting to be send. When they become connectable
again I turn compression back off...
Why not create a separate directory for every node's (pkt) files? Like SeparateBundles in hpt or fileboxes.
Packed echomail is a bad idea with the high frequenies as one
will run out of file extensions after 36 polls. (.WE0-9 +
.WEA-Z).
It could indeed. My tosser just keeps using the Z if that's reached.
Which doesn't seem to cause problems, as far as I'm aware of...
As long as the inbound at the destination system gets processed, that's fine. If not, it will run out of filenames there since trying to rename 12345678.WEZ to 123345678.WE0 will most likely fail.
I sometimes turn on compression for links that are offline for a bit
longer then 1 or 2 days. Because with the high frequent tossing that
happens today, the outbound directories quickly fill up with hundreds
of pkt files, which I don't like. With compression turned on there
are at most 7 files for each (offline) node waiting to be send. When
they become connectable again I turn compression back off...
Why not create a separate directory for every node's (pkt) files? Like SeparateBundles in hpt or fileboxes.
Why not create a separate directory for every node's (pkt) files?
Like SeparateBundles in hpt or fileboxes.
Fileboxes are not BSO compatible. So the behaviour regarding flow
files in fileboxes is undefined. So that can cause problems if a
tosser and mailer try to access the same files at the same time...
And you would still have hundreds (or even more, if the link remains offline) of .pkt files in that directory. So it doesn't solve
anything...
Fileboxes are not BSO compatible. So the behaviour regarding flow
files in fileboxes is undefined. So that can cause problems if a
tosser and mailer try to access the same files at the same time...
I think what Oli meant to say was: Put the PKTs in some per-node folder and leave the LOs in the normal outbound. That way the outbound is
clean, you see what's waiting without having the fuzz of all the PKTs laying around.
And you would still have hundreds (or even more, if the link remains
offline) of .pkt files in that directory. So it doesn't solve
anything...
You'll have 1 ?LO (and probably one ?UT) per node in the outbound and a lot of PKTs in the "per node"-folder. Quite easy to delete, if needed (-:
You'll have 1 ?LO (and probably one ?UT) per node in the outbound
and a lot of PKTs in the "per node"-folder. Quite easy to delete,
if needed (-:
Ok I understand. (And there's only the .?lo file)
But your tosser would have to support that, and it currently
doesn't...
Ok I understand. (And there's only the .?lo file)
But your tosser would have to support that, and it currently
doesn't...
I'm in the (un)lucky position, that i develop my tosser myself, so
i could do that.
But it could also be done with a 3rd party tool that moves things away after your tosser prepared the original outbound.
It's quite easy:
- Check/set BSY
- Read LO files
- If there's a PKT referenced in the outbound, move that PKT away
- Update the LO file with the new path.
- Clear BSY
FlexToss developer there. FlexToss was created back in the days to handle swiss backbone traffic.
I'm in the (un)lucky position, that i develop my tosser myself,Yes, me too... ;-)
so i could do that.
It's quite easy:
- Check/set BSY
- Read LO files
- If there's a PKT referenced in the outbound, move that PKT away
- Update the LO file with the new path.
- Clear BSY
The new path also needs to be configured somewhere! If you have a configuration program, that's probably the most work to add that in
there. ;-)
FlexToss developer there. FlexToss was created back in the daysIs there a website or download for FlexToss?
to handle swiss backbone traffic.
Anyway I don't find it a usefull addition for my tosser, I rather spend my time on something else!
I was not telling, that i wanna do that, i only mentioned that it's possible. But then: How many sysops are nerd enough to inspect
their outbound manually? For now, i count two. (you & me)
Is the original discussion about the insecure outbound over? Can
we focus on something more serious now? ...duck&cover... :)
The new path also needs to be configured somewhere! If you have a
configuration program, that's probably the most work to add that in
there. ;-)
I was not telling, that i wanna do that, i only mentioned that it's possible. But then: How many sysops are nerd enough to inspect
their outbound manually? For now, i count two. (you & me)
Anyway I don't find it a usefull addition for my tosser, I rather
spend my time on something else!
Like watching the outbound, the log file and enabling and disabling %COMPRESS settings manually? ;-P
I'm not convinced we convinced Alan.
There is nothing serious about Fidonet.
There is no content to transfer. You don't need a road if nobody
travels.
That is incorrect. There is content to transfer.
Your actual scenario is two machines that have a road that is
used for nothing more that to prove "look, there is a road".
In the case of ping we want to know if the road is open.
To that end I just sent a ping to a node I want to communicate with
and am just awaiting a reply. If I don't get a reply to that ping I
will send the mail directly.
Do one step back and get aware that insecure compressed ping
creates problems for no reason other than to have a problem to be
solved.
Ping creates no problems at all whether it is sent/received directly
or routed. It is just a tool available to us.
Now the cat is out of the bag. You really do want to change the
default behavior of the whole fidonet for insecure compressed
mail.
That is up to the husky developers.
I am only trying to solve the issue I reported. The husky developers
may have read my comments, I don't know. But I have not asked them to change anything, and I will not.
I agree with you that nodes should always send netmail
uncompressed
Then please follow this path. It is the solution with no issues.
This is the path I am on, as I said. Repeatedly.
Be a good coordinator and teach selfish nodes why to turn off
compression for insecure netmail. Do not support their annoying
behavior by working around.
Selfish nodes?
I will certainly suggest this to nodes when I can do that.
I think that's the right thing to do. I don't think I am in any kind
of position to change the way this does happen in fidonet.
You are going to force the whole fidonet to support compression.
I suggested nothing of the sort. Individual nodes can and will support
the compression methods they choose, if any.
You can do what ever you will on your system but stop forcing
me/us to support compression. You don't know what is running on
"our" side.
I am not, and will not force anything on anyone.
There is no arc support for the Pandora, for example.
http://repo.openpandora.org/?page=all&search=unarc
What will be then? Would you simply say i'm no longer part of
fidonet if i can't support compression?
Of course not. Why do you suggest that I would?
Or will you invent a "noarc" flag for the nodelist that any node
does know that i do not support compression?
I would not invent a noarc flag for several reasons.
A netmail will leave my node uncompressed but it may be compressed
along the way, this is beyond my control. That may or may not be a
problem for the destination node.
You intention for easy going with compressed insecure mail will
backfire then because you have to install the "unarc" flag
condition to the whole fidonet systems including yours. See the
top of this mail, you're creating issues where are none.
I am creating no issues. Archived netmail is in my insecure inbound
and I need to decompress it so it can be tossed.
I find no policy or FTN standard that directs nodes not to do
that and that is why it happens.
I showed you two times already. The *transfer*! format is defined
by FTS-0001.
If a node transfers an arcmail bundle to my node (as we are discussing here), has any policy or standard been violated?
Compression after agreement is defined by the echopol and that is
a freedom i'd like to see for the whole fidonet. You can use any
compression tool you like if both parties agree.
What echopol? My own use of compression/decompression (if needed) is
not defined by echopol. It is simply used as needed.
If one does not agree or the parties never talked about
compression before then no compression is the solution that will
work on the whole fidonet.
I agree with you. Nevertheless there is compressed mail in my insecure inbound that sits there until I find and deal with it.
Mail arrives in my inbound as it is prepared by other nodes. This is
not a configuration or choice on my part.
My goal in testing is to fix what's broken or to make things work
better when that is possible.
That is incorrect. There is content to transfer.
Then it is worth a secure connection.
insecure inbound that sits there until I find and deal with it.
Best practice: Delete it.
That is incorrect. There is content to transfer.
Then it is worth a secure connection.We've been over this so I'll make this short.
insecure inbound that sits there until I find and deal with it.
Best practice: Delete it.
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,049 |
Nodes: | 15 (0 / 15) |
Uptime: | 35:22:46 |
Calls: | 235,760 |
Calls today: | 1 |
Files: | 60,337 |
D/L today: |
61 files (130M bytes) |
Messages: | 287,786 |