Network 版 (精华区)

发信人: zzn (爱你到内伤), 信区: Network
标  题: mms协议英文资料(23)
发信站: 哈工大紫丁香 (2003年08月23日10:56:07 星期六), 站内信件

ASF UDP/TCP Packet resynchronisation
Ok, what can be done if we get a corrupt packet? Or maybe it doesn’t arrive 
at all?
IP packets (and thus the ASF packets within) can be tested either by checksum 
testing (requires access to the IP packet checksum in header), or maybe just 
by testing the ASF packet for a valid sequence number.
Unfortunately, UDP has no way of recovering a lost or corrupt packet because 
UDP is connectionless and therefore has no handshake to re-request the 
packet. Bad or lost UDP packets are simply deleted if its checksum is 
incorrect, resulting in a missing packet – and a missing count sequence. UDP 
checksum testing is done within the Winsock32 layer (for windows) of which we 
have very little control.
TCP on the other hand does recover lost and corrupt packets quite effectively 
using its checksum and re-send protocol. For this reason, TCP is far more 
robust when it comes to downloading and even real time viewing is improved. 
TCP packets very rarely get lost. UDP packets can and usually do get lost in 
the system, especially under heavily congested network conditions.
For TCP packet viewing / recording, there is not much to do other than 
receive the data as it arrives and then deal with it accordingly. TCP takes 
care of all the headaches of errors, lost packets and anything else that 
comes along 99.9% of the time.
For UDP packets, the application must take care of what happens next. If a 
packet gets lost of out of sequence, the player can do either of the 
following:-
1) Request the missing packet again from the server by using a UDP re-request 
command (see below). When this happens, the lost packet (we detected a 
missing UDP sequence count) gets re-sent to the viewer. Hopefully this 
re-sent packet arrives in time and is placed in the buffer before its 
actually viewed. This being the case, the viewer is unaware of any loss and 
the media plays normally. If the re-sent packet arrives too late, noting can 
be done and a missing frame or two will cause the media player to freeze 
momentarily.
2) We can ignore the bad packet (maybe just ignore that we lost a sequence 
count) and keep playing, the player would resume on the next good packet 
anyway.
The best course of action regarding lost packets is still under 
investigation. A re-send is of course necessary for a download, we do not 
want to miss any packets if writing a file. But for a viewing session, it’s 
probably not needed.
MMS application protocol does handle lost or corrupt packets even when using 
UDP, but it handles them within media player, using the MMS 07 command for 
TCP seeking and the so called ‘beef food’ command for UDP re-sends.
Below shows what is known about the UDP re-send command – I’ve named it the 
‘beef food’ command. This command is very different to the normal TCP MMS 
commands we have talked about already. This command is sent across a UDP 
datagram to the server and has its own defined command make up. This command 
is sent to the server on port 1755, just like a TCP command.
[4 bytes] Header ID.
This value is fixed as 0x0d, 0xf0, 0xef, 0xbe.
Strangely, this value reads ‘beef food’ in big endian hex mode! Just like 
the ‘boob face’ fixed bytes in an MMS command. This must be a joke:0) [4 
bytes] Client ID
(found in 0x15 command from server) [2 bytes]
Always 0x01, 0x00 fixed value – could be UDP command 01. [2 bytes]
Shows how many packets are to be re-sent to the client (count of fields 
below) [Variable length]
4 byte fields. This is a list of packets to be re-sent. Note the value of 
each field can only range from 0 – 255 (even though it’s a 4 byte field), 
after that its wraps around to zero again.
It is unknown whether other UDP commands exist, but for now, this one is very 
useful.
If the requested re-send packet fails to respond from the server, media 
player gives up after 5 attempts. 
--
    既然选择了远方，就让我们风雨兼程吧
    人生最快乐的事　莫过于
        有了目标，并为之奋斗!

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.243.49]