Subj : dosxnt To : Jasen Betts From : Paul Williams Date : Fri Sep 27 2002 01:06 am Hi Jasen Betts, hope you are having a nice day JB>Plenty of other explanations exist. I can see no real reason not to JB>simply use sequential numberrs seeded from the date/time when the JB>program was started. unless messages are generated by the node faster JB>than the clock ticks it shouldn't be a problem. That actually was a problem here when I ran the gateways after I'd made a hardware change. Prior to it the system was tossing out 1 msg anywhere from 10 to 90sec apart, however after changing the drive controller to one w/ both a hardware cache and a 286/12 to run things it started tossing msgs on the order of 5-20 msgs/sec. Since systems up stream were *not* using the msgid in dupe checking there were a lot of them being killed off. If I were to run the same setup on a more modern system then I'd be looking at upwards of 40msgs/sec being tossed and needing msgid's created. JB>FWIW if the node makes more than about 60 messages per day there's an JB>approximately even chance of a reprated msgid in any given three years... Well the one upside if I understand the spec right is that a duplicate msgid is only a dupe if it's in the same echo. So even though the below looks like a dupe, it's not as the areatag is different. AREA: 80XXX @MSGID: 1:387/710 2AD45CD7 AREA: HAM @MSGID: 1:387/710 2AD45CD7 PW>> The one upside to the program though is that when it hits one that's PW>>too large it doesn't trash the entire pkt. Msgs before it will have the PW>>selected kludges added but the one it chokes on and those after PW>>are left untouched resulting in a pkt that still fully usable. JB>that's good... It also doesn't leave a mess behind, though I don't see anything in the way of housekeeping in the code. PW>> Right. Unfortunately there's several programs that don't have PW>>msgid generation in them. Synchronet BBS being one still under PW>>development that still doesn't. JB>I guess the syncronet node could run this program on its own messages. JB>running the program on remotely generated messages may be against the JB>rules. That's the way I run it here. When termail exits it runs the archiver to pack up all the pkt's. What I did was to rename the archiver and then write and compile to exe a small batchfile which runs pktfix on the pkt and then runs the archiver w/ the right cmdline options. PW>> The kludge that I don't understand is the CHRS one. Why is there a PW>>`2' placed after the value? For ex, I use pktfix to add CHRS IBMPC PW>>but the code adds (or did add as i changed it in mine) CHRS IBMPC 2 JB>I think that's correct, dunno why. Dunno either, although I have on occasion seen some that didn't add the 2. Most that didn't were from Z1 which is why I thought it might be a zonal thing. Which spec is that covered under, do you know? PW>> Should be interesting to see what you come up w/. JB>yeah... JB>That code chokes on messages with CR LF ^A kludge but although 88 I hadn't noticed anything like that here, looking at the pkt's generated by termail I don't see 0x0D 0x0A 0x01, just a 0x0D 0x01. -=> Yours sincerely, Paul Williams <=- .... OOooooohhhhh! AAaaaaaaahhhhh!!!! - Andrea Chalfin --- Terminate 4.00/Pro * Origin: Nothing can stop me--not even common sense (1:387/710) .