Why is sliding window only 1/2 the space? Wouldn't overlap occur only
when the window was the full size of the receive space?

The problem isn't about the window overlapping the full space, but
rather retransmitted packets coming in late. Let's say that you have a
receive window that's 75% of the space. You get a packet that's at the
end of it. Is it a packet that's 3/4 of the way forward, or one that's
1/4 of the way behind you that's been retransmitted?



After a collision on an ethernet, does everyone delay, or just the
ones involved in the jam?

Good question. It's only the ones involved in the collision. This
leaves open the possibility for someone who wasn't originally
transmitting to notice that the medium is idle and send in that time
when the others are backing off. This does/did happen, it wasn't fair,
but then again, it wasn't too bothersome. If they collided, they'd
eventually start backing off as well.



What is MACAW?

It's MACA + W, which is Multiple Access with Collision Avoidance for
Wireless LANs



I'm lazy - what's the URL for the errata?

It's about 120 characters because of the location and tracking
information that gets added in. Trust me - start with
http://www.cs.princeton.edu/~llp and take it from there.



How does the sender know the RWS initially? Is there some predefined
window size?

In TCP connections, the sender and receiver basically set up the
connection before sending data, and this kind of information can be
exchanged at that time. It also gets updated as the connection
progresses.



How does the wireless hub listen to multiple nodes if they happen to
be at the same frequency? Or does the hub just wait until the
frequencies are different?
and
Can a wireless access point handle/ease collision arbitration?

Presumably, if the nodes are talking with the access point, and the
access point can hear both of them, they can hear the messages from
the access point. In other words, they can tell that the access point
has sent a CTS and is should be receiving data (even if they can't
hear the data being sent). So, they avoid sending in the time that
they believe the access point is receiving.



Does 802.11g support both b&g hardware?

Take a look at the bottom of
http://grouper.ieee.org/groups/802/11/Reports/tgg_update.htm
It seems to indicate that the 802.11g group was formed to look
at a higher-speed format that's interoperable with 802.11b.
I would imagine that any reasonable implementation would work
with b and g.