Date: Sun, 10 Jan 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #10
To: tcp-group-digest
TCP-Group Digest Sun, 10 Jan 93 Volume 93 : Issue 10
Today's Topics:
In-Reply-To: AA4RE's DPMI et al...
MID dups problem - Revisited (3 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sat, 9 Jan 93 20:50:05 PST
From: aa6ed@algedi.ampr.org (aa6ed)
Subject: In-Reply-To: AA4RE's DPMI et al...
To: tcp-group@ucsd.edu
Your interest in DPMI and Borland Turbo Pasal for Windows Version 7.0
caught my interest. I sent a check to Dave Larton, N7JQJ on August
18, 1992 in hopes of getting a copy of the Executable and Source code
for your AA4RE software, but since then, received nothing, the check
was never cashed. I assume that it was lost or destroyed.
In August, I was running MSYS software under Windows 3.1, and suffering
greatly with problems with comm port access. I really wanted to re-do
your software as a Windows 3.1 application, complete with the Windows
comm drivers at 9600 baud. The interest is still there, but since then
I am now running the WG7J JNOS code with 4 ports at 9600 baud with
16550 chips, and it's working fine.
With the increase of 386/486-33++ computers and the popularity of Windows
and OS2, wouldn't it be of your interest to use your Version 7.0 software
to create a Windows 3.1 executable version of AA4RE BBS? I think the
popularity would soar (I assume you don't need BPQ code to function).
I would like to request information as where to find your source on this
Internet thing (it's new to me, have a friend with a boeing.com account).
The UUCP/Internet address listed below still has bugs, it will
probably not find me yet. AA6ED@AA6ED.WA.USA.NA probably isn't too
reliable as well, the AX.25 network being as it is. If I don't hear
from you, I'll try to contact you later, or cc: a copy to myself c/o
'wahltv@atc.boeing.com'...
I tried to send this direct to you, but my gateway wouldn't allow 'bang'
requests to be originated.
73's
AA6ED
|-----------------------------------------------------------------------|
| Ham : aa6ed.ampr.org [44.24.103.157] William [Bill] Bytheway |
| LLBBS : (206) 271-4657 (300/1200/2400) 11108 SE 184th Place |
| Voice Phone : (206) 271-4476 (w/recorder) Renton, WA 98055 |
|-----------------------------------------------------------------------|
| Return mail from UUCP/Internet should use : algedi!aa6ed@Data-IO.COM |
|-----------------------------------------------------------------------|
------------------------------
Date: Sat, 9 Jan 93 16:23:10 PST
From: Bill Healy <healy@moriah.ee.unr.edu>
Subject: MID dups problem - Revisited
To: tcp-group@ucsd.edu (tcp-group)
>>> Well, with a simple addition to the forward.c file of WG7J1.07b, the dup
>>> MIDs problem is history! This is the snip of code I added to TNOS to
>>> handle the problem. I've sent it to Johan, and he is adding it to JNOS.
>>> The code changes the bid from $abcde_host.domain to $abcde%destinationuser.
>>> This makes it unique for each message.
>
>> WHat is abcde, the message number?
>
> Yep! Thought that was obvious, guess not!
What's to prevent 2 or more systems from generating the same MID on
messages to a common destination_user? If n1abc and n2abc send alot of
messages to each other, say 30 of them, they will use MIDs 1%n1abc to
30%n1abc and 1%n2abc to 30%n2abc. This means anyone whos sequence number
is under 30 can't send a message to n1abc or n2abc. MIDs should be based
on the originating system, not the destination user.
Bill N8KHN
------------------------------
Date: 09 Jan 1993 22:56:12 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: MID dups problem - Revisited
To: healy@moriah.ee.unr.edu
You write.................
What's to prevent 2 or more systems from generating the same MID on
messages to a common destination_user? If n1abc and n2abc send alot of
messages to each other, say 30 of them, they will use MIDs 1%n1abc to
30%n1abc and 1%n2abc to 30%n2abc. This means anyone whos sequence number
is under 30 can't send a message to n1abc or n2abc. MIDs should be based
on the originating system, not the destination user.
........................
This MID method has a CHANCE of a dup, but very slim. The original way,
based on the originator DEFINITELY DOESN'T work!
There is a difficulty, in that a MID/BID must be 13 characters or less.
Since it is quite easy to get into 5 and 6 character numeric sequences,
after adding a '%' to look different that a standard BID, you have only
about 6 characters left. To make them unique if they were generated from
an alias, the difference is only the destination name.
Anyone has a better idea, I'd welcome it. I simply took the problem and
found a solution. Give me a way to take the 5-6 digit number, the
originating station call, the destination station call, and place it into
13 characters and I'll be grateful. ;-)
The chance that two NOS systems, would have a message with the same MID
number to the same user, in the same finite time period are not very great!
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
------------------------------
Date: Sun, 10 Jan 93 1:43:48 PST
From: Bill Healy <healy@moriah.ee.unr.edu>
Subject: MID dups problem - Revisited
To: tcp-group@ucsd.edu (tcp-group)
> This MID method has a CHANCE of a dup, but very slim. The original way,
> based on the originator DEFINITELY DOESN'T work!
It doesn't work when one message is being sent to more than one person.
Even a slim chance isn't good, a system should not have the possibility of
affecting what another system can receive.
> There is a difficulty, in that a MID/BID must be 13 characters or less.
> Since it is quite easy to get into 5 and 6 character numeric sequences,
> after adding a '%' to look different that a standard BID, you have only
> about 6 characters left. To make them unique if they were generated from
> an alias, the difference is only the destination name.
>
> Anyone has a better idea, I'd welcome it. I simply took the problem and
> found a solution. Give me a way to take the 5-6 digit number, the
> originating station call, the destination station call, and place it into
> 13 characters and I'll be grateful. ;-)
Ok, modify the MID based upon whether it's going to the first, second,
third, etc recipient.
pseudo code time:
If not the first recipient then
make the MID_modifier equal to A for recipient #2, B for #3, C for #4
D for #5, etc....
if length of MID is 13 then
new_MID = MID_modifier + rightmost 12 characters of MID
else
new_MID = MID_modifier + original_MID
EX. If the original MID is 12345@ka1abc the MIDs will be as follows
Addressee #1 : 12345_ka1abc
Addressee #2 : A12345_ka1abc
Addressee #3 : B12345_ka1abc
etc.
The other solution is to explode multiple recipient messages and store
them individually, that way they'll have their own unique MIDs.
> The chance that two NOS systems, would have a message with the same MID
> number to the same user, in the same finite time period are not very great!
Most AX.25 BBS systems retain MIDs/BIDs for 30 days or more, you have to
remember that every system along the path will retain the MIDs/BIDs also.
Bill N8KHN
------------------------------
End of TCP-Group Digest V93 #10
******************************
******************************