ObservationJust testing things with NET 5 and was u
sing raw packets in the tests. When Ipolled the HUB there we
re in excess of 100 packets waiting for me. Fidopollpulled d
own 100 then exited cleanly. I imported the packets and was stumped
as I was looking for a netmail that was not imported.After po
lling the HUB again I pulled down a further 7 packets including the
netmail one. My conclusion - there a limit of 100 files per fidopoll
session? Which works well I guess if you're talking compressed packets bu
tnot so great if you're running raw packets on a busy system
?Perhaps there needs to be a way for fidopoll to be a
djusted so that theperson polling can raise or lower the lim
it of max files per fidopoll?Another idea - get fidop
oll and the system it connects to (assuming it'smystic) to r
eport of the total number of files to be sent/waiting forcol
lection upfront at the start of the transaction. That way someone pol
lingknows theres 107 files waiting to be pulled down, and fi
dopoll could show apercentage of how many files had been dow
nloaded as the session continued?Dunno, some ideas an
yway to help the end user understand what files arewaiting t
o be sent and perhaps (if the 100 max rule is to remain) alert them
a repeat poll is advised after one ends as x files still remain to be collected.RequestCould you look at adding an
other prompt that the sysop can enable in the FSEso that whe
n they go to compose a message the FSE inserts a line of text at
the start (much like prompt 464 does when someone replies to a post) that inserts a date/time of message being composed.e.g.
"On Sat, 29 Dec 2018 09:42:14 +1300 put pen to paper and said..."
So using the same format as MIS does now but suggest adding the + to the TZ field. Perhaps having the day/date and the time as two separate fields that could be added to the printed string would be nice.e.g someth
ing like this..; msgtext intro text header &1=date &2
=from &3=initials &4=timeXXX On &4 put pen to pa
per and said...Ideally having the time as an extra fi
eld to prompt 464 would be grand also.; msgtext quote
header &1=date &2=from &3=initials &4=time464 On , &4
pondered and said...For me it's nice to see
an option to include the date/time a message is
composed written in to the bodycopy.
Thanks for considering. :)A
lso is there an MCI code that displays the session type o
f the logged inuser? Telnet / SS
H etc.? I'm looking around but just can
't confirm or denythat at present.

���������������������������������������� ���� E�[email protected] ������ W�bbs.nz ��� ���� K�keybase.io/avon ��������������

--- Mystic BBS v1.12 A42 2018/12/28 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Just testing things with NET 5 and was using raw packets in the tests. Whe polled the HUB there were in excess of 100 packets waiting for me. Fidopol pulled down 100 then exited cleanly. I imported the packets and was stumpe as I was looking for a netmail that was not imported.

I looked at it does cap at 100. I increased it to 200 now in the latest
build.

Another idea - get fidopoll and the system it connects to (assuming it's mystic) to report of the total number of files to be sent/waiting for collection upfront at the start of the transaction. That way someone polli

Done. Although I seem to remember that there might have been BINKP implementations (non-Mystic) that would choke on an information frame being sent after authentication. Something to keep an eye on I suppose, but I went ahead and added it anyway.

You'll now see something like "1-Remote Queue: X files X bytes" when you connect to another Mystic BBS, but its still only going to show you the
number of the files in the queue which are capped at 200 now.

I also added the build date/time too. I don't think I can change the version line as it is actually documented in a specific format if I remember correctly. There are some mailers that do not obey the format, but I don't want to be one of them. Instead it will send it separately directly after the version information though, so it should look like:

1-Version: Whatever
1-Info: BUILD 12/12/1212 12:12:12

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 30 Dec 2018, g00r00 pondered and said...

I looked at it does cap at 100. I increased it to 200 now in the latest build.

Thanks! that's good. For nodes who want raw packets and are a bit slow to poll those numbers to transfer can creep up quite quickly I find.

Done. Although I seem to remember that there might have been BINKP implementations (non-Mystic) that would choke on an information frame being sent after authentication. Something to keep an eye on I suppose, but I went ahead and added it anyway.

Coolio, yeah I'll keep an eye on logs and I'm sure other will too.

You'll now see something like "1-Remote Queue: X files X bytes" when you connect to another Mystic BBS, but its still only going to show you the number of the files in the queue which are capped at 200 now.

OK so does this mean the x files will only ever report a max of 200 files per fidopoll session, even if say there are 225 files sitting to be pulled down?

I also added the build date/time too. I don't think I can change the version line as it is actually documented in a specific format if I remember correctly. There are some mailers that do not obey the format, but I don't want to be one of them. Instead it will send it separately directly after the version information though, so it should look like:

1-Version: Whatever
1-Info: BUILD 12/12/1212 12:12:12

I agree with the approach and thanks for doing this I just think having extra session data can help debug stuff when folks are saying I'm running A42 but
in reality it's a build from 6 hours earlier etc.

I would ask you consider adding some mention of the OS that the server is running on as we've already seen at times there can be an issue with the software but it might be limited to say the Pi or Linux 64 etc. so to see via this logging what BBS is running what ver/os is really helpful to get a sense of what's going on.


���������������������������������������� ���� E�[email protected] ������ W�bbs.nz ��� ���� K�keybase.io/avon ��������������

--- Mystic BBS v1.12 A42 2018/12/28 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

OK so does this mean the x files will only ever report a max of 200
files per fidopoll session, even if say there are 225 files sitting to
be pulled down?

Right. It doesn't know there are 225 files if they aren't queued so it would just report 200.

I would ask you consider adding some mention of the OS that the server is running on as we've already seen at times there can be an issue with the software but it might be limited to say the Pi or Linux 64 etc. so to
see via this logging what BBS is running what ver/os is really helpful
to get a sense of what's going on.

I think I can add that into the build frame or maybe just add an OS tag too.

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Hello g00r00!

30 Dec 18 13:17, you wrote to Avon:

Just testing things with NET 5 and was using raw packets in the
tests. Whe polled the HUB there were in excess of 100 packets

Done. Although I seem to remember that there might have been BINKP implementations (non-Mystic) that would choke on an information frame being sent after authentication. Something to keep an eye on I
suppose, but I went ahead and added it anyway.

You'll now see something like "1-Remote Queue: X files X bytes" when
you connect to another Mystic BBS, but its still only going to show
you the number of the files in the queue which are capped at 200 now.

M_NUL TRF netmail_bytes file_bytes is supported by most, if not all BinkP mailers.

I also added the build date/time too. I don't think I can change the version line as it is actually documented in a specific format if I remember correctly. There are some mailers that do not obey the
format, but I don't want to be one of them. Instead it will send it separately directly after the version information though, so it should look like:

1-Version: Whatever
1-Info: BUILD 12/12/1212 12:12:12

The only thing I see in the binkp/1.0 protocol specification (http://ftsc.org/docs/fts-1026.001) is that the mailer_version is restricted to any printable characters (including spaces.) I don't see anything that would preclude adding your build date/time to the mailer_version portion of the M_NUL VER frame..

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)

You'll now see something like "1-Remote Queue: X files X bytes" when you connect to another Mystic BBS, but its still only going to show you the number of the files in the queue which are capped at 200 now.

M_NUL TRF netmail_bytes file_bytes is supported by most, if not all
BinkP mailers.

Yes, but it doesn't provide the same information. I find the information it supplies to be quite useless (as did the people requesting I add what I did), in addition to the fact that its unintelligible.

There isn't anything to support for either of them; They're just information frames that can say whatever they want.

--- Mystic BBS v1.12 A42 2018/12/31 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)