RE: For Windows clients

pap@TIAC.NET
Sat, 7 Jan 1995 15:13:14 -0500


Matthew,

Thanks for the comments. Regarding same as written;

>Michael Sattler <msattler@jungle.com> regularly posts
>"CUSeeMe Nicknames (with comments) List" (last was 3 Jan 95)
>to this mailing list. Thanks to Michael for an excellent
>and current reflector list. The reflectors in this list
>often show a World Wide Web site. These can be a gold mine.
>
I did receive Michael's list. Good work. Is it a little Mac-centric though?

>Limit of 5 reflectors in MRU list:
>I can't put my hands on the documentation, but it is well
>known that the Windows version of the CU-SeeMe client
>(latest is ver 0.34b3) will not keep more that 5 reflector
>names, regardless of whether you put them in by menu or
>edit the .ini and try to number higher. It's just one of
>those things.
>
Documentation ... quest of the Grail. I could see that the app does a simple drop
down list w/o scroll. I'm sure scroll lookup will follow. The app seem to be just
circular buffering the latest (5) connections. I'm not sure what role MRU listings
play. Having hammered on the .ini file per detail notes in Michael's list, I do not
think it matters in this version.

>Location of cuseeme.ini:
>Your Windows directory (usually C:\WINDOWS)
>
Roger that..

>One way to browse a lot of reflectors:
>A) Telnet to your ISP and start your mail reader. Display
>Michael Sattler's most recent Reflector List with the site
>you want on the top half of your screen. Start CU-SeeMe and
>resize it quite small in the lower right of the screen.
>You should now be able to <num lock> and key reflector
>IP addresses directly into the dialog box. To get a new
>site's number, <alt esc> to your telnet session, <space bar>
>(at least for pine) and there's another site displayed.
>B) Just like the above but work from a downloaded copy
>of the list displayed in say Notepad (finer scroll control)
>
I have been doing something like the above, though not looking at the latest list. I
did a cut and paste session from mail to a refl.txt notepad file, iconized it and put it
in the group with CU. Highlight the name/ip in the .txt file, "CntrlC" or "Edit
Copy", click open the connection selector in CU - highlight if necc., "CntrlV",
done. Just need to figure out how to program the right mouse button to do "CntrlV"
for the session <:). The notepad file is nice for session notes, too.

>One way to reduce "Closes" of the CU-SeeMe client:
>Go after sites rarely active - ie that one that's live about
>5% of the time - these sites that don't send back a steady
>packet stream are able to be disconnected - therefore check
>them first. Leave the "certain to be live" sites till the
>end of your session as you will certainly have to "Close"
>your client, and this may cause a Winsock GPF.
>
This one troubles me a tad.. I made some more observations this AM, primarily in
light of what Steven Womble wrote on the 6th;

I quote;

Apparently, CU-SeeMe was up and running with 4 users (3 lurchers - 2
PCs, 1 Mac and 2 senders - PCs) sending/receiving to an AIX reflector
when there was a network glitch which cause CU-SeeMe to loose contact
with at least 2 (possibly all) of the clients connected. When the
network got back to normal CU-SeeMe tried to re-establish connection
to the clients (which possibly killed their local CU-SeeMe program),
but couldn't reconnect. During this time CU-SeeMe repeatably kept sending
out requests to open port 7XXX which caused some of the CU-SeeMe clients
to completely hang and overload our 16MB Token Ring network enough to
bring other systems on the ring almost unusable.

Has anyone seen this happen before? It seems to me that CU-SeeMe should
have a timeout value to stop sending requests after 1-2 minutes of
failures.

unquote

I found that the app in the environment on this system, will show all the signs of
behaving as expected; closing 'v' sessions.. wait a min. or so.. close the
connection.. close the app.. try to do something else that looks at the IP stack...
stack is hosed up to any new port connection. The only fix so far is to terminate the
modem session and re-connect. What I envision may be going on is that the
reflector persistance has been terminated at the local IP port running the app and
perhaps messing with the socket or some other things a bit, however the gateway
to which I connect (I also use a 14.4 or 28.8 cslip access) is probably still running a
process for my port connection which may still be jammed with feed and useless
consumption of bandwidth. If I were to assume that all was well and leave the
connection process up (for mail, etc.), go to lunch, or worse, leave for the holiday,
it could get nasty for the gateway and it's net (replicate the scenario a few times).
I may have some concurrent system/stack wierdness, possibly due to due to other
WFW extensions tests, which show up now and then, but not consitiently. What
do you think?

>Just a quick observation:
>I am delighted to get the chance to receive video from around
>the world (over my 14.4 SLIP connection). I'm not hollering
>at the development team to add colour, sound and 30fps func-
>tionality to a remarkable and innovative prototype. Let's keep
>in mind the research community provides this software to us
>without charge. Thanks very much.
>
I guess what you are saying is that it suits your needs as is. I thought that this forum
was enabled to assist the (NSF funded) development of what will likely be one of
the most innovative means of promoting understanding that we have left!! I feel
that if it is not well received by network administrators in it's current form, maturity
will be slowed. This is not hollering - consider the implcations - it is a concern that
it may be viewed disruptive to the bandwidth that is currently available to us today.
I, for one, will test it with caution. Kudos to the team that is making it work!

//Not knowing does'nt worry me as much as not learning.//

P.A. Petricone <pap@tiac.net>