Re: Run CU-SeeMe Client and Reflector Simultaneously

Andrew Clarke (
Thu, 19 Mar 1998 19:43:46 BST

** Reply to note from Thu, 19 Mar 1998 02:47:18 EST

> On Mon, 16 Mar 1998, Brian Godette wrote:
> > Java-CU should really be called Java-NV since that is what it really is.
> > It's simply the CU-SeeMe B&W codec handling and RTP communication routines
> > from NV 3.3 rewritten in Java. Since it uses seperate ports on the client &
> > server it can be run on the same system as the reflector.
> The German guy that wrote JavaCU provides the source. Is there any way for
> JavaCU to be written to NOT require NV? I talked a bit with Andrew Clarke
> about this awhile back. The docs to JavaCU mention something about there
> being a 15kbps limit with Java applets. I'm not sure if that's true or
> not. If it's not, a Java port of CU (though it would have to be receive
> only I imagine) would be quite interesting to see.

Yep, JavaCU is definately JavaNV, and can therefore co-exist with the reflector on the same
computer (or mor appropriately, the same ip address). I don't see anything preventing it
being converted into a 'proper' CU client, even for send/receive; of course as their isn't a
workable multimedia Java API at the moment, it won't be possible to so any video capturing in
a cross-platform manner but it would be possible to create a sort of 'billboard' system to
transmit graphics (CU Tamagotchi anyone? :). As to the 15kbps limit, well any decent JIT
compiler should make the application/applet bandwidth bound as opposed to CPU bound, remember
that Sun are selling a Java web-server which they claim is faster than apache (it may not be,
but it's certainly no slouch). Implementing MJPEG would be a little more challenging, but not
beyond any good programmer (which rules me out :).

However, a 'true' CU client cannot be on the same ip address as the reflector, unless the
server it was on was multi-homed and the ref and client were bound to different interfaces
(possible in Java 1.1 and above).

This would make an interesting project for someone with more spare time than me, as it is my
current interesting project has just been restarted because I thought of a better way of doing

Coming Real Soon Now[tm], JRefControl will give Enhanced Reflector operators the ability to
remotely configure and control their refs in a way rivalling what White Pine offers now:
password protected access; access levels; persistant bans; bans based on nickname/ip
combinations; pretty graphical refmon application; lots of other funky stuff that I haven't
figured out how to do yet. All written in 98.3% pure Java for cross-platform goodness which,
with regular use, will prevent dandruff coming back.

Ok, don't expect anything soon, but I will try to get something out at some point before the
end of the millenium.

On a related note (and for a change this *isn't* a slight against White Pine) this whole
cross-platform issue is interestng. Brian's ref to my sure knowledge is running on three
different operating systems, Linux/Unix, Win32 and OS/2, because it's written in very standard
ANSI-C. As an example, porting the ref to OS/2 took me the best part of 2 hours, which is
entirely down to Brian's clean code, I only added the #ifdefs for the OS/2 specific parts
which don't number highly at all. I'd be thrilled if WhitePine created some Java-based CU
technolgy (I believe that MPCS has a Java based front-end, but I really don't know much about
it), maybe as part of their 'componentisation' of CU, after all, ActiveX is a failure as an
internet technology :)

Ok, enough of me, I'd be interested in anyone else's ideas on this matter.

[To unsubscribe from the CUSEEME-L mailing list, unplug your computer and never turn it back
on. Ever. Have a nice day.]

Andrew Clarke - Will taunt people for chocolate
PGP Public Key available on request
"Having your nuts nibbled off by a Laplander, that's a way to die." - Nothing interesting that way lies