Next: Client-side Multicast API
Up: Reliable Multicast Protocol
Previous: Reliable Multicast Protocol
- When to start reading packets from the multicast address
Once the join and the request have been sent it is unclear whether
waiting for the HTTP Req Ack is more important than accepting the
multicast packets. We have chosen to wait for the Ack from the
server before accepting the multicast packets. This is primarily
because we do not intend to buffer the HTTP response within the
flow.
- Reliability
The underlying transport protocol is only
partially reliable. It does not guarantee that a message will get
delivered to all the end clients. This would not be acceptable for
the application in consideration. Therefore in our design we add an
additional layer of reliability to handle messages that are not
received. All messages have application level sequence numbers. The
server periodically broadcasts the name of the object that is being
multicast, the number of segments and the starting, ending and
current sequence numbers. The proxy then detects missing sequence
numbers and sends requests to the server requesting retransmission.
- Late Join
When a proxy receives an HTTP ACK, we have
two choices. The station can wait for the start of the file or start
receiving packets immediately and request the rest of the packets.
Joining at any point in the session would be more efficient but will
have extra overhead. We choose to go with joining at any point in
the session. The client will start looking for the control packet
and will start receiving packets from that point. For small files
the server would put the control packets only in the beginning of
the file. This way the stations would get all the packets in
sequence if there are no errors. However for large packets where it
would be inefficient to wait, the server will insert the control
packets periodically and this period is configurable. This allows
the proxy to buffer the flow, and do an early leave from the group.
- HTTP ACK Pause Time
When the server finishes multicasting the
file, it waits for a certain amount of time to wait for all the
proxy to send back URL ACK message back to the server. If at the end
of this pause time all clients have acknowledged the complete
receipt of the message the server stops multicasting the packets.
Otherwise, the server starts retransmitting the message
again. Currently this timeout is a fixed value of 1 s. This needs to
be made a function of the largest RTT among all the proxies and the
number of proxies listening to the multicast session.
Next: Client-side Multicast API
Up: Reliable Multicast Protocol
Previous: Reliable Multicast Protocol
Matthew James Sanders
Wed Dec 2 16:23:52 EST 1998