Re: White Pine CUSeeMe Version 3.1.1

Brian Godette (bgodette@idcomm.com)
Mon, 20 Apr 1998 13:47:36 -0600


At 10:21 PM 4/17/98 -0300, you wrote:
>At 11:21 AM 4/16/98 -0500, Jason Williams wrote:
>>> The problem with private chat sending messages publicly when the other
>>> user has disconnected also seems to be fixed.
>>
>>Unfortunately, the problem sending 3.X private chat to users with Enhanced
>>CU 2.X still seems to have problems. Luckily, Brian Godette's Enhanced
>>Reflector fixes this.
>
> Yes, and that's a completely different thing. And not a bug... The older
>clients have never been able to tell the difference between private &
>public chat. That's been a problem since GeekTalk. And yes, correctly used

Hmmm, not a bug... ok lets call it a missing feature, a feature that has
been present in GeekTalk since it's first release and always in GeekPC (and
the first piece of code I wrote called privchat that I handed off to Mark).
In anycase it was a pre-existing method (aux Priv) with it's own set of
rules such as putting <privately> on all private chat to clients that don't
report supporting aux Priv, which is exactly what my ref does.

>GeekTalk will modify the chat so that it's flagged as private. I know.
> What Brian did is to modify every private chat packet outgoing to an older
>client. I'm glad he took it apon himself to do that, it's a big help to
>some people. Modifying users chat as it passes through the server is a
>choice not all people would agree with, however. Is there an option NOT to
>do that for certain conferences? Not that it's a big deal one way or the
>other, just curious...

It could, but why? The client *should* work that way to begin with.

>
>At 02:36 PM 4/16/98 -0400, David Toole wrote:
>>problems when switching. IMHO, software should work, period.
>
> Now that's a nice, broad blanket statement. I take it you mean every piece
>of software should work with everything you expect it to. In this case, all
>versions of any client claiming to be CU-SeeMe should work with all
>servers/reflectors claiming to support CU-SeeMe. That's an aweful tall
>order, isn't it?

Really? We are talking reflectors here and not client-to-client
interoperability right? If we are talking reflectors, as I said from a
client point of view there's only two.

>At 12:55 PM 4/16/98 -0600, Brian Godette wrote:
>>My take on this, based on the 3.1.1 release notes, is that they are having
>>problems related to switching between old style CU headers and RTP headers
>>when switching refs. It's my understanding that WP Ref 2.1 and up support
>>RTP headers from the new WP CU clients (3.0 and up). I would guess there
>>would be no problems switching refs as long as you stay exclusively on WP
>>2.1 and up or ERef/Cornell/WP 2.0.
>
> Hmmm... that would also (I assume) be based on an email conversation we
>had? Sorry about not responding... I had WAY too much to do for awhile

Naw, just a guess and only a guess as I haven't installed 3.1.1 to have a
first hand look at it.

>there & lost the thread... At any rate, I think you're wrong here.
> First off, a technical point. The 2.X reflectors didn't do RTP, so if
>there's a problem that's common between 3.X and 2.X then it can't be based
>on RTP.
> Next, based on testing reports I've seen, it can't have anything to do
>with RTP. Apparently connecting to certain servers, then disconnecting, and
>RECONNECTING TO THE SAME SERVER can fail. Thus, it has nothing to do with
>state. Now I'm not a client guy, so I can't get technical here (and I won't
>in a public thread anyway...) but I thought I'd point that out.

Ok clear enough. The only thing that came to mind was something messed in
the TCP connection routines..

>
>
>At 03:55 PM 4/16/98 -0500, Jason Williams wrote:
>>How about the somewhat random spewing of someone's text in the chat
>>window? That seems to be different from the private chat bug.
>>
>>An old email from Brian concerning this:
>>"BTW there appears to be an oddity with WPCU 3.1.* in regards to chat
>>recovery. Seems that if it doesn't know about the client that's making the
>>recovery request (hasn't ever received an OC packet from them) it'll send
>>the requested chat lines as public (client->group instead of
>>client->client). This behavior is of course induced by a conference with
>>too many participants for it to list"
>
> Just a random thought on that one... It seems to me you guys do some
>incredibly detailed testing/debugging... I don't suppose you ever
>considered mailing your tests and/or results to WhitePine to get a fix?
>Since it's obvious that you are very concerned with the quality of our
>software (and I think that's great), why don't you send the data to the
>beta-test program rather than blasting WhitePine in a public mailing list?
>You've already worked out the problem, why would you...
> Oh, never mind.

I have in the past (recent even) with no real response. And the problems
listed on the client portion of my web pages have been available for a
fairly long time (ever since the WP 2.0.* clients). Fortunately it looks
like those problems are resolved, can't say for sure as I've not had a
chance to take a close look at 3.1.1 with the analyzer.

>
>At 04:03 PM 4/16/98 -0500, Jason Williams wrote:
>>Yep..I agree :)
>>But is it really any worse than the 3.X client not being fully compatible
>>with their OWN 2.1 client with private chatting? At least now, their 3.1
>>client works with other White Pine reflectors. A step in the right
>>direction. :)
>
> Again, it's not compatability that's an issue. The private chat
>sends/recieves just fine between 3.X & 2.X clients. The problem is that the
>3.X client doesn't stuff "<privately>" (or whatever the ERef is inserting)
>into the outgoing chat. If you're sending priv chat to a user that can't
>tell, do it yourself. Right click the participant name... if they don't
>have the ability to download thier contact card, they probably can't tell
>the difference between priv chat and public. Make a macro in 3.X that
>inserts "<privately>" in the text, click it before you type, and send that.
> *sigh*
> It's not a bug, it's just up to YOU to mark it.

In my opinion it is a bug considering that private chat was not developed
by WP. If you're going to support a third-party
feature/protocol/technology, at least do it right.

> And if people NEED to have the server do it FOR them, then the ERef has
>that ability now. Personally, I'd rather just do it myself then have
>anything else leading me along. Or for that matter, having the ERef stuff
>something into a message I've already marked...

It doesn't... it checks for <privately> first of course, did you think I'd
only do half a job?????

> BTW, I know the arguement that it makes it easier to tell if someone is
>harrassing you with private chat... But most people can tell pretty quick
>if they are the only ones getting obnoxious messages. And stuffing
>"<privately>" in the chat won't stop people from sending it anyway...

Thus... NO-GEEK and CONF-NO-GEEK, how nice :) and of course those settings
don't apply to EGeek32 as it has a better way to handle it <wink> <wink>.

>
>At 12:55 AM 4/17/98 -0500, Jason Williams wrote:
>>key! White Pine's market is NOT the Cornell/Enhanced Reflector market or
>>one in which Cornell/WP 2.X clients co-exist with 3.X clients. And that's
>>where all the problems seem to be arising.
>
> Given that, why does this follow:
>
>>I have no problem with White Pine optimizing their client for use on MPCS
>>servers and their 2.1 reflector. What I do have a problem with is when
>>they BREAK compatibility with older clients and don't seem to think much
>>of it.
>
> If you state the one, the other become irrelevant. I think you're wrong on
>the first statement, however... In fact I KNOW you're wrong about the
>Cornell client compability issue. It may be broken today, but imperfect
>humans have bugs. They get fixed in beta cycles. Be patient, we're not done
>yet... :)

Which is why I'm not making a real big stink about it. When I have time I
may take a real close look at 3.1.1.whatever-it-is-at-the-time, but that
may be months off the way things look, so odds are it'll end up to be the
production version.

>
>>reflectors makes sense. But does that also mean they should develop their
>>own independent protocols that work solely on MPCS servers and nowhere
>>else? If you do that, then why have the name CU-SeeMe at all? That's
>
> Ok, so lets assume you're basing this on the RTP mention that Brian made
>earlier. What difference does it matter if the WhitePine client supports
>RTP, H.323, and Pete Jones' Spiffy standard? (Ok, I made the last one up...
>:) So long as it handles the basic Cornell-defined standard, it's CU-SeeMe.

And currently, it's a bit broken in regards to the basica Cornell
standard.... but again, no biggie, still beta.

>And so long as the reflector(s) handle the same standard, everything's
>happy. Thus, you can have one protocol that speaks only to MPCS's, another
>for NetMeeting, another for point-to-point client connections, and the
>basic CU-SeeMe for everyone else. And six more if you like... No problem.
>
>>kind of like saying "there are two versions of Win95..one version runs one
>>set of applications while the other version runs another and they can't
>>cooperate".
>
> It's more like saying there's one kind of Win95 and it runs 16 bit apps
>AND 32 bit apps. Which is pretty much like saying you support the old AND
>the new.
>
>>There's also not a "myriad" of reflectors. As far as I know, the MAIN
>>one used is Brian Godette's Enhanced Reflector (And Brian performs a great
>
> Actually, there are four as I see it. The base Cornell reflectors, the
>WhitePine 2.X reflectors, the ERef, and the MPCS. And I don't know WHAT the
>MAIN one is, but I'd LOVE to see a survey! How bout a show of hands...
>Everyone that runs a ref that's reading this list: What type/version of
>reflector/server do you use?
> This should be interesting, eh? :)

In terms of protocol used there's two, RTP with MPCS and Cornell with
everything else, three types if you want to include the TCP setup in WP 2.*
refs. As for the servey... just count up the numbers off of Streak's
scanner, this of course is only a valid count of public (or near public)
reflectors and disregards any installed MPCS/WP systems inside businesses.

>At 11:43 AM 4/17/98 -0600, Brian Godette wrote:
>>>White Pine knows the ins and outs of their server software (i.e., Reflector
>>I'd argue that.... considering how long some long standing problems and
>>(relatively obvious) security issues still exist in it.
>
> Ok, THIS is actually where I decided that I was going to respond... It's a
>LOOONG way to go to get here, eh? :)
> I think I pretty much know the ins and outs of my server software....
>(note that I said *my* server software, I'm very protective of it :) But I
>don't want to get into a pissing contest with Brian over who can be more
>technical when describing the inner workings of the code and/or protocol.
>First off, Brian's VERY good at what he does. I'm impressed that the ERef
>is maintained by ONE guy! And second, if there are issues you've got with
>the MPCS, send them to me offine. You've got my email address... I'd be
>happy to look into them.
> MORE than happy to hear about anything new! :)

I've already filled you personally in about the security problems,
including the one line of code to fix it, and to at least two other WP
employees as well, yet it remains (be glad ChatCU isn't available).

>
>>>2.x and MPCS), so wouldn't it make sense for them to limit support for
>>>their client software (CUSeeMe 2.x and 3.x)? Tech support can only do so
>>>much....
>>This doesn't make since considering they claim to be backwards compatible
>>with the Cornell software, and as stated above there is only *TWO* flavors
>>of reflectors from the client program's point of view.
>
> Mmmm... and as stated above, there are FOUR versions of the
>reflector/server from the Tech Support point of view.

Still only two, it does not matter if it's a Cornell, ERef, SRef, whatever,
they're all the same to the client (with the exception being color works on
ERef). If you want to include the conference box, it's three.

>
>>reflector software is out there from a *client* point of view. There's only
>>*two* "systems" in use here, the standard Cornell headers, and what WP uses
>>with Ref 2.1 and MPCS, which involves RTP headers (standard set by MBone
>
> And again, the 2.X refs don't do RTP. Never did it, never will.

Which still leaves two, so?

>
>>>Pine be any different? I don't hear anyone complaining about these
>>>company's limiting the server software which can be supported by their
>>>clients.
>>
>>They don't complain because those systems are self-contained, there is no
>>compatibility issues with other publicly available software from third
>>parties. The reason wht WP *IS* different is they have, once again, a
>>backwards compatibility issue to live with.
>
> That's an EXCELLENT point, and THANK YOU for making it!

Just thought I'd point that out to the guy, I perfectly understand what
obsticals face the client and why it's a wholely different beast than
developing something in-house or to the h263 "standard".

>
>>So you'd be perfectly happy if Microsoft made a "technical decision" that
>>resulted in say... Win98 running Microsoft software only, or charging money
>>for Internet Explorer and having it work only with web sites on NT running
>>IIS 4.0? Think about how much damage that would do to their market share.
>>This is exactly what *does* and will happen when products built on existing
>>products break backwards compatibility with the existing products, and is
>>exactly why iVisit, VocalTec, ICUII, VDOPhone don't have this problem.
>
> Why does everyone pick Miscrosoft as a shining exemple?
>
> How about if someone changed (added to) Java then fixed it so that only
>THIER browswer understood the new stuff? (I've bumped against these myself)
>Or had outstanding agreements with a company for compatability between
>operating systems and as soon as the contracts ran out, changed thier OS in
>ways that made all new binaries incompatable with thier former "partner"?
>(Talk to IBM about OS/2 Warp) Or intentionally implemented OS specific
>extentions to Java that make a cross platform language/development tool
>system specific? (COM extentions to Java, ActiveX plugins, ...) Microsoft
>has done all that... and lets not get into the problems with the supposed
>wonderful 32bit enhanced filesystem for Win95...
> Mind you I'm only staying with very recent exemples here. :)

<sarcasm>Because everyone just LOVES Microsoft.</sarcasm> And because they
actually have a history of doing exactly that (see above for recent
history, hehe).

> Ok, my point here is not to bash Microsoft. Just to clear up a few points,
>and to say that everyone has problems...
> Thank you for pointing them out. Rest assured that people on both the
>client and server teams are recieving your input. The problems are being
>addressed. As far as compatatbility goes, WhitePine clients are STILL going
>to have compatability with the Cornell refs. If (as Brian says above) there
>are no differences between the ERef and the basic Cornell refs (as far as
>the client is concerned), then there is nothing to worry about (as far as
>the ERef is concerned).

As far as I know, to a client it's no different except that it does route
color. All the expected protocol interaction is there. However support for
a few things outside of what can be defined as a standard Cornell protocol
client do exist in it, and have no relation to anything any existing client
does.