Rick W. wrote:
> I would have to say that your belief that there is some tone in my
> message is unwarranted.
Not going to debate this. I'll just say I read your reply to someone
else's question/comment first without knowing who it was and wondered
what the deal was.
But since you are sincere and have no agenda, we can proceed!
> For the record, I did not find an explanation
> of the Pilot station on the web site where one would think it would be
> clearly explained and I appreciated your clearing this up.
>
>
This is a fair question, and one we have not made a big deal about. We
needed something to call the stations that committed to being available
24x7. They are not just PMBO's, or BBS's, as their intended function is
more than that. (Though they serve that role as well)
> I do not share the view that having multiple networks is necessarily
> good if that makes things more complex (increases the potential for
> failure).
Again, like it or not, WL2K is the prevalent ham radio messaging system
in use right now. In an emergency, there is a very high probability that
the people you will need to swap email with will be on WL2K.
It's also an advantage just to be able to send to a callsign, no other
routing needed.
Ignoring this factor isolates a new technology and makes it doomed to
failure just like some of the pre-TCP-IP/SMTP mail networks. Build a
bridge, interoperate, and value is added.
It also makes sense to have traditional SMTP capability without
depending on the WL2K network. Both for availability and independence
reasons.
> These networks do fail and they sometimes have long delivery
> times, but the promoters tend to gloss over such information and make it
> sound like there is 100% up time. There up time is very good, but
> nothing is perfect.
Delivery time in the modern email world is pretty quick. If you are
seeing long delivery times in WL2K it has to do with how you connect.
They made a design choice which makes sense for HF that add's a nuance.
Your mail is not kept on every pmbo/server. It moves to the one you last
connected to. Connect to a new one, and it may be a few minutes before
it is sync'd there.
There are valid mail store design issues involved in this approach. The
design changed a bit with the implementation of the WL2K CMS's, which do
tend to stay in sync, but the I believe the concept is the same. You
clearly cannot keep everyone's mail on every server, you end up with a
giant synchronization issue. Huge bandwidth and expense trying to keep
large message stores in sync when geographically dispersed like the WL2K
servers (properly) are.
> If I send a message with one system and the message does not go through,
> then I suppose I could try another system as an alternative. But would I
> even know that there is a problem? Probably not until much later, and by
> then (hours later) the message that was bottlenecked, may be finally
> getting through.
>
If you get a message ID, the message was sent. If you did not, you can
resend or try alternates. You have the same level of confirmation that
you do with your traditional ISP email client. There is no guarantee
that the message was delivered, just that it was accepted by the server.
> You did not mention it, but isn't the main value of using the Winlink
> 2000 systems is the ability to route traffic through many different
> methods, primarily internet, but also VHF and HF and find the recipient
> at any point in the system, even if they change location? Just like
> having web based e-mail vs. fixed ISP e-mail. No other system has this
> feature.
>
WL2K discussion tends to be very polarizing, even in this group. People
tend to lump WL2K in with Pactor, when in fact one can be used and has
value without the other.
So I don't promote WL2K extensively as it's heavily promoted in other
areas. Based on past threads, my belief is that users of this group
already have an opinion formed, valid or not, about WL2K. So I don't
revisit. Ham's either understand or they don't.
But your point is valid, and one of the reasons we see interoperation
with WL2K as critical.
> He had trouble connecting but later in the day was eventually
> able to do it and I received duplicate messages just short of an hour
> after he sent them. Not too bad for time, although this was a one line
> message. He was able to use the ARQ mode and should have been able to
> send a much longer message.
>
There have been changes in how to use the multi-line ARQ modes for
messaging. It's not a capability we have promoted widely as we are still
tuning to align the tool's capabilities (PC-ALE/MARS-ALE) with the
messaging needs.
The challenging issue is that DBM/DTM was really designed to behave like
a serial stream, even though in PC-ALE it looks like a block text transfer.
So we are having to come up with an approach to delineate the end of a
message, as the protocol does not allow for that intrinsically. We are
not clear on whe
