[standards-jig] Pub/Sub for JNG?
dave at dave.tj
Wed May 1 19:56:29 CDT 2002
Van Gale wrote:
> Dave wrote:
> > Dial-up users also like to download data, you know. . .
> > - Dave ... who likes to let people optimize at their own bottlenecks :-)
> > Craig wrote:
> > >
> > > --Craig, who likes to optimize at known bottlenecks.
> Dave, I think you're missing several important points.
Well, enlighten me, sire :-)
> Probably the most
> important point you're missing, as evidenced most recently by your signature
> quoted above, is that _without measurement_ you are wasting everyone's time.
> The point of Craig's signature is _known_ i.e. _measured_ bottlenecks.
> Speculation is worthless. We want to see hard data, not opinion. If you
> can prove total system improvement by using compression then I'm all ears.
> If you are just voicing an opinion, especially an opinion that goes against
> previous measurements, then you are wasting a helluva lot of people's time.
I don't think I speculate when I say that people behind dial-up lines
also like to download (and often upload) large amounts of data, as well.
Compression and UDP are both very useful for those users.
> Now, also regarding the quotes above. I'm paying the bills for my server,
> not the user. I want the user to have a good experience (otherwise what's
> the point of running a server) but I'm not going to increase my real money
> costs just so the user can receive a compressed 200 byte message 10 msecs
> faster than an uncompressed 300 byte message. That's what I mean by total
> system improvement.
Not all servers support Jabber Message Rules. Why should all servers
support compressed connections?
> As far as UDP goes, many other people have made critical points that you
> seem to be ignoring so I won't go over them again.
Will somebody please bring up one point that would appear to imply that
UDP is useless to almost everybody? If not, then allowing people to
use UDP if they prefer causes us no harm, and may actually benefit some.
> I'll just add one point
> that hasn't been brought up. Writing your own protocol on top of UDP would
> probably be a decent idea if you are a proprietary company with full control
> over client and server development. However, for an open source project you
> will immediately shut off a large number of client developers who don't want
> to reimplement the protocol in their language of choice....
The UDP proposal that I came up with (quite off-handedly, as well -
I'm sure many others can think of even better specs) doesn't reimplement
most of TCP. It merely consists of a sequence number for each datagram,
followed by the actual data. TCP can't beat that ;-)
> especially when
> they see everything you added to UDP is already in TCP.
I guess I'd have to admit that I kinda answered that above. . .
> Actually, I will go over a point already mentioned by Joe Hildebrand and
> it's one he correctly said was VERY important.
> - The network will soon begin to require applications to perform congestion
> control, and those applications which do not perform congestion control will
> be harshly penalized by the network (probably in the form of preferentially
> dropping their packets during times of congestion).
...and it's one that I already answered (and if you don't believe me,
I'll dig up the URL) - the PPP network that dial-up users connect to
isn't likely to start requiring congestion control anytime soon, since
there is only one computer that can transmit on any given channel,
so there's no contention to contend with :-)
> UDP datagrams are the first to go everytime. 20% of UDP packets dropped at
> the metropolitan access points (MAE, etc.) is a good day. This means the
> reliability you build on top of UDP is going to have to work much much
> harder than TCP.
Hmm ... that's actually a rather easy quantity to measure: try nslookup
a few times, and see how many of them work without resorting to TCP.
(You can just kill TCP at the firewall for a couple of minutes as you
test, if you want to be sure.) If you've got a reasonably close DNS
server, none of them will fail. The 20% statistic is probably only in
the congested areas, for long-distance traffic. With all the Jabber
servers on the 'net, I'm sure you can find one that'll be able to receive
most of your datagrams (and if not, just stay with your standard TCP
connections - I'm not proposing that we eliminate them). Arguing that
UDP shouldn't be allowed simply because some people may not be able to
use it productively isn't very wise, is it?
Dave, who wonders how he always rubs people the wrong way. . .
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards-JIG