On 4/5/99 1:53 AM Jeff King ([EMAIL PROTECTED]) wrote:
>Steve Dimse K4HG wrote:
>>
>> >So what is wrong with making something that is both technically sound
>> >*AND* that the average ham can use? You know, they are not mutually
>> >exclusive.
>>
>> Nothing is wrong with that, but that isn't the attitude you have
>> expressed over the last week:
>
>(examples of my pompous attitude deleted)
>
>Well, what is wrong with my attitude? Just because I won't cut hams a break
>that won't LEARN the technology. So what? Hey, its not like I
>am on the APRSSIG user list doing this so cut me a break.
>
I didn't say there was anything wrong with it. You just keep changing
your position. It was to show vaccilation, not pomposity, that I quoted
you. One message you say screw the average Joe Ham, the next message you
say you want to make something that they can use. You are free to take
either position, it doesn't matter to me, but pick one. Which is it?
>>
>>
>> >As I have stated on a number of occasions, the authors of the various
>> >APRS flavors should put some consideration into the transport layer.
>>
>> I think this is a bit harsh. Bob, Kantronics, PacComm, and others have
>> put a lot of thought into the "network" design.
>
>Well, you basically said this yourself already. BTW, I never mentioned
>PacComm or Kantronics so I don't know why you are bring this up.
>
I'm talking about WIDEn-n, callsign substitution, and other features they
have added to the TNC's for APRS "networking".
>Is it such a crime to think it could evolve? Better or complex does not mean
>it has to cost more or be hard to use. I have a duplex spread spectrum radio
Perhaps it could evolve, perhaps it could be better. I definitely admit
the possibility exists. I know I'm not the one to do it, and I'm
pesimistic about your, or anyone else's, ability to do it. I've said, and
I truly mean it, prove me wrong. I'm just really getting bored of
theoretical discussion. Prove me wrong and earn gloating rights if you
can!
>BTW, I remember when you were first writing the
>APRServe I suggested you look at the convers code on NOS. You hadn't
>even heard of this and apparently didn't even bother. It's fine with me
>if you constantly want to reinvent the wheel, but don't call it "talk" when I
>cite the large amount of prior art that exists for this field and you chose
>to ignore it.
>
>From what you told me at the time I knew it wasn't going to be the
simplest, most reliable way to implement my plans. I was designing an
internet based client/server system, so I wrote one using my own TCP/IP
connections. Sure, I could have added NOS to the server (and which would
in turn do the TCP/IP connections), but it would have been slower, less
reliable, and more complex to implement.
>> >I don't think this has been done. If they don't wish to do this, then they
>> >shouldn't stand in the way, or attempt to suppress the efforts of those
>> >that in good faith wish to improve things.
>> >
>> I haven't seen or heard anyone suppressing or standing in the way of any
>> transport layer development. But then, I haven't seen any working
>> systems. A lot of talk the last week, but talk is cheap. If you produce
>> something that works, and it gets unfairly trashed by someone, then you
>> have a reason to complain. But to throw out a bunch of ideas and expect
>> people to adopt a technology that doesn't yet exist is a little
>> unrealistic, don't you think?
>
>Of course it would be unrealistic. Problem is, the so called "new" ideas have
>been around since the 70's and 80's and many hams have already implemented
>them. You only need look around or read some of the papers that have
>been published. BTW, I remember when you were first writing the
>APRServe I suggested you look at the convers code on NOS. You hadn't
>even heard of this and apparently didn't even bother. It's fine with me
>if you constantly want to reinvent the wheel, but don't call it "talk" when I
>cite the large amount of prior art that exists for this field and you chose
>to ignore it.
>
No. What I say is all this prior art can't be merged into a system that
is better for the APRS user, or the digi owner, than exists now. I'll be
happy to have you prove me wrong. But for God's sake, stop talking and
get on with it!
>> I would love to see you or someone else come up with something better
>> than exists now. I just don't think you can do it without requiring more
>> time, money, and skill than hams are willing and able to expend. Please,
>> prove me wrong! (Hint...words aren't going to prove it, at least to me!)
>
>OK, so
>tell me what "better" means to you, and then I will consider taking you
>up on your challenge or find the prior art that backs up my "words". I
>already
>have something in mind, but it seems we have different realities of "better".
>(see the DGPS/BUSY tone suggestion above)
>
I don't think there is anything that needs to be fixed. You are the one
convinced it is horrible and needs to be redone. I don't want prior art,
the needs of APRS users are different than others ham radio has
confronted. The challenge is for you to design and build an APRS RF
network that is accepted by the APRS community. They are the ones that
ought to judge if your system is "better", and if so if it is better
enough to justify any additional complexity and cost. God bless the Free
Market and Alan Greenspan!
>
>> >What would be involved in supporting it would be disclosing the APRServe
>> >protocol
>> >
>> There is no separate protocol for APRServe. It is simply lines of text as
>> they come out of the TNC's, the usual APRS format packets that the client
>> programs already understand. KISS...
>
>> discussion. I spent a long time with Dale going over the inner workings
>> of APRServe so that his program was fully compatible, as he includes the
>> bidirectional messaging and filtering functions of APRServe which are not
>> particularly easy to understand.
>
>OK great, so this is documented somewhere?
Yes, there are a number of documents on my web site that discuss the
filtering algorithms and the third party messaging. Also see my paper in
the 97 DCC procedings.
>I'd guess your using a token
>server of some sort for the third party messaging.
>
Actually not. APRServe is designed to be redundant. You can take down
either of the two (three if I ever get around to it) primary servers and
the other(s) take up the load without any intervention. The client
programs even switch servers automatically. A token server would increase
the complexity. I move the transmit decision outward to each IGate. The
full time ones are connected to both servers, so there is no lag if one
goes down. Each incoming packet is checked to see if it is a message or
position report that should go out on the local RF net, and transmits it
if needed.
>
>> However if your data is not compatible, then it is better placed on
>> another server.
>
>At the level of the server, there is no reason for it not to be compatible.
>I've been discussing RF networking, hidden terminals and other lower
>layer RF transport issues. I'd hazard to guess your server isn't even
>compatible
>at this level with real APRS. It requires a PAD between it and the RF medium
>at a minimum.
>
Forgive (or in your case, rejoice in) my ignorance, what does PAD stand
for?
It requires a TNC and radio. Those damn twisted pairs on the eithernet
cable just don't radiate RF effectively enough to have them feed directly
from the internet to RF ;-). The TNC is connected directly to the IGate
computers, no additional hardware is needed.
Steve K4HG
