(REPOST) 2 workstations Point-to-Point: My Experiences

newland (newland@pcb9.gaa.aro.allied.com)
Fri, 5 Jan 96 09:45:18 CST

Hi again, I posted this a month ago and there are more questions
re. 2 CUSM machines directly connected. Hope this helps.



Date: Fri, 1 Dec 95 10:04:50 CST
From: newland (newland)
To: cu-seeme-l@cornell.edu
Subject: 2 workstations Point-to-Point: My Experiences
Content-Length: 3829

Hi all,

I have read some discussion about point to point conections not
involving a reflector. I have done some of this and will share what
I have learned, which is by no means a complete set of tests.

I experimented with 2 PC's connected via a serial cable, instead of
modems, and using Trumpet Winsock. I found this will work only if
the IP address of the name server is removed, as the other side cannot
do a name lookup since it's not a server. The domain name can be
left there, it is not used if there's no name server IP entry.
The host's IP address must have a unique IP number on each end,
you can use anything but and I have used and .1 successfully. The communications are set up as
hardware handshake, you can pick SLIP or PPP but it must be the same
on both ends, and the comm rate is set by entering a common baud rate
value into both sides (ex. 19200, 38400, 57600, 76800, 115200), when
you restart Winsock it will initialize the comm device to that speed.

When setup is complete, start Winsock on both machines, it will enter
SLIP mode right away, there's no dialing to do. The TCP/IP sockets
are active on both ends at that point. Start CUSM on both ends in
any sequence, then connect to one from the other. It should open up
within a few seconds.

With this setup, I have found what effect cranking up the comm rate
has on dynamic motion, and at what point the CPU is overloaded with
comm packets and cannot keep up with compression/decompression of the
pix. On my 386/25, I lose data at 57600 but not at 38400. This does
not account for audio, although it should work using White Pine alpha.

One other observation, the send rate cap on one end is apparently set
by the 'transmission min kb/s' on the other end. I recall some of the
discussion about reflector dynamic rate adjustments, this must be
(guess) where the initial rate number is taken from by the ref,
and no adjustments happen when 2 clients are connected to each other.

I have connected to my brother's Mac in FL over phone lines point to
point using 28.8k modems (at 24k), having the above setup and my end
(PC and Winsock) set to auto answer, and he makes the call. To set
the PC to auto answer, I put Winsock into 'manual dial' mode and
issue the auto answer modem command 'ats0=1', then Escape into SLIP
mode. The modem picks up, negotiates the line, and the CUSM connection
can be started from either end. We were unable to make the Mac
auto answer, but neither of us are MacTCP wizards and we didn't
happen across the right things to change, although we did fiddle a lot.

I have found with any PC version of CUSM, including White Pine, that
after a connection is broken, CUSM *must* be exited and restarted from
scratch to successfully reconnect. If not, the connection will be made
and immediately status goes to 'disconnecting from ..', regardless of
what else you do.

We found in our PC to Mac experiments that you need a mighty powerful
Mac to keep up with a PC, surprising to me. The Mac appears to
run out of horsepower at a fairly low comm rate, compared to the PC.
This may be a false conclusion, we are still playing with other factors,
but on his end, at 24k comm modem to modem direct, with no ISP
servers or reflectors in the line to 'filter' your UDP packets, and
the modems correct for all errors (when allowed, normal default for
most modems), he would get major packet loss and a sprinkling of
pix elements on anything but a PowerMac, and somewhat even at that.
The audio (16kb delta-mod) worked reliably at 24k but only with a
big Mac (my PC is a Pentium 60) and with video stopped.

Hope this info helps somebody.
CUSM sure is a long term learning experience once you start playing
with it.

Grant Newland
star@gvi.net (home)
newland@pcb9.gaa.aro.allied.com (work)