精华区文章阅读

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

MMS Flags (prefix data for some commands)
Flag fields are found in prefix data fields in some (not all) MMS commands.
This is an attempt to describe how they work and how the client and server
can modify the value of these flags as the protocol progresses during
initialisation.
The exact purpose of these flags has been difficult to examine because their
state rarely change or show meaningful data. But over time and
experimentation, a pattern is starting to emerge. We will now show what is
known about these flags fields.
Generally, flags are ‘echoed’ by the server to the client player and can be
modified if the state must be changed for any reason. Therefore, by the end
of the exchange from client to server and back again, we are left with a
valid flags state that both client and server have agreed to. It seems the
main purpose of these flags is to determine the current player and server
version types and network timing methods to use for both those versions.
Either UDP packet pair or TCP 0x15 command packets can be selected by the
flags state. Read the MMS commands and UDP packet pair sections for further
information on these methods.
< MMS protocol flags start here >
Command 0x01 to server -> start flags something like 0xf0f0f0f0.
If this value starts with 0x00000000, then no modifications are carried out
as below – all flags remain zero for all states all the way to the end. This
is true for very old media player versions less than 6.4. (like the original
windows 95/98 install version).
Command 0x01 to client -> Server echo of previous command 01 flags.
However, flags can be incremented by 1 if the server does not support any
timing packet methods. This is true with old server versions less than 4.0.
As an example: if flags were 0xf0f0f0f0 from the client, the server could
change the value to 0xf1f0f0f0 (little endian) if both UDP and TCP timing
methods are not supported, else no modification is needed - echo 0xf0f0f0f0.
Command 0x18 to server -> Client flags indicate what timing tests to do, if
any.
Flags start as 0xf0f0f0f0 and can be modified as follows :
increments by 0x01 if the TCP timing method is required,
increments by 0x811 if the UDP packet pair method is required,
decrements by 0x01 if no timing method is required by the client. This is
true when the player has its ‘Auto Detect’ internet speed tick unchecked.
This is because it then uses a pre-defined connection speed and does not
require timing packet tests.
Flags = 0 if the player version is very old, less than 6.4, in this case no
timing tests are done.
Command 0x15 to client -> Server echo of flags from the previous 18 command.
No modifications are needed.
However, if the TCP method has been requested as the timing test, we send 3
packets of this 0x15 command (with random test data). If any other test
method is required, or maybe non at all, then only one 0x15 command is sent
with no random test data block.
Command 02 to server -> Client echo of flags from previous 15 command
No modifications are needed.
Command 02 to client -> Server echo of flags from previous 02 command.
No modifications are needed.
<end of flag modifications – we are left with a completed flags state. We
can now determine what timing method (if any) to use for this session >
It seems very likely that any of these commands could alter the state of
flags depending on the command’s purpose. But we have only seen the changes
outlined above. This seems to be a reasonable basis for understanding the
operation of flags during the modification of the flags state.
--
在这里倾听夜暗的歌声/冥冥中谁奏响沉寂百年的古琴/我又看见夏日里美丽的黄昏/
白天奔忙于生活的人/傍晚就三三两两走到一起：/是南方这样的温暖时常发生

路草长满街道/幸与不幸从不同的着落点退出/他们错过记忆里的某件事/
仿佛一只只岩鹰/方向改变了身体仍在憧憬中/越过一座座灰色的城市

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

Network 版 (精华区)