http://replay-address:port/ivs-IVSGetUnitInfoThe expected response is an XML document (content-type
text/plain
) like:
<?xml version='1.0' encoding='UTF-8'?> <UnitInfo isn="00055-09166-55204" nickname="Jtl" />
http://recipient-address:port/ivs-IVSSendNotification?isn=00055-09166-55204&size=1044&data=00000001000000000000000000000001The actual
data
is much longer - 1044 characters, as specified by the size
argument. The isn
argument is the recipient's ISN, presumably so that it can triple check that its the intended target; this triple checking isn't actually done, however.
The data in the data
argument is a hex encoded structure. It's decoded as if it were variable-sized, but it seems to be fixed in the current version; the offsets aren't correct for simply loading it in memory and using it as-is: it's actually stored in a file and read in in pieces.
Offset | Size | Name | Notes |
---|---|---|---|
0 | 4 | unknown1 | Always '1'. Possibly a version code for the rest of the structure |
4 | 4 | unknown2 | Always '0' |
8 | 4 | unknown3 | Always '0' |
12 | 4 | unknown4 | Always '1' |
16 | 4 | isn_field_length | Always '18', but this is actually checked and used by the receiver to parse the rest of the structure |
20 | 18 | recipient_isn | The recipient's ISN, as a NUL-terminated ASCII string in the standard output format |
38 | 4 | magic1 | Always '0'; verified by recipient when decoding the ReplayShow member. Possibly a sub-version for this part of the struct, or for the AddressBookEntry. |
42 | 4 | magic2 | Always '3'; verified by recipient when decoding the ReplayShow member. Possibly a version for the ReplayShow structure itself (compare with the 'ReplayChannels/3/' directory). |
46 | 32 | sender_abe | AddressBookEntry for the sender |
78 | 444 | replay_show | ReplayShow structure for the show being sent, with the index_size and mpeg_size members filled in |
Offset | Size | Name | Notes |
---|---|---|---|
0 | 4 | unknown1 | Always '1'. Possibly a version code for the rest of the structure |
4 | 4 | unknown2 | Always '0' |
8 | 4 | unknown3 | Always '0' |
12 | 4 | unknown4 | Always '1' |
16 | 4 | isn_field_length | Always '18', but this is actually checked and used by the receiver to parse the rest of the structure |
20 | 18 | recipient_isn | The recipient's ISN, as a NUL-terminated ASCII string in the standard output format |
38 | 4 | magic1 | Always '0'; verified by recipient when decoding the ReplayShow member. Possibly a sub-version for this part of the struct, or for the AddressBookEntry. |
42 | 4 | magic2 | Always '5'; verified by recipient when decoding the ReplayShow member. Possibly a version for the ReplayShow structure itself (compare with the 'ReplayChannels/5/' directory). |
46 | 32 | sender_abe | AddressBookEntry for the sender |
78 | 512 | replay_show | ReplayShow structure for the show being sent, with the index_size, mpeg_size, and evt_size members filled in |
http://replay-address:port/ivs-IVSGetFileChunk?isn=00055-09166-55204&start=0&chunksize=4194304&filepath=/name/mpeg/108822343.ndxThe
isn
argument is the sender's ISN; like the isn
argument in the sending notification request, this could be used to verify that the proper RTV is being talked to.
The start
argument is the file offset to begin sending at. Compare with HTTPFS's readfile
=pos= argument.
The chunksize
argument is the amount of data requested for this request. Compare with HTTPFS's readfile
=size= argument.
The filepath
argument is the full, Replay-internal, filename being requested. These always start with /name/mpeg
.
There's an optional crc
argument that the Replay doesn't actually use; it defaults to the value '0'.
The response is sent using HTTP 1/1 chunking in its standard way. Ignoring that, the response body is simply a chunk start line, a chunk of the file, and a chunk end line.
The chunk start line looks like #####REPLAY_CHUNK_START#####4194304#####0
and is terminated by a CRLF. The first number is the requested chunk size (which may be larger than the chunk actually returned, if the file is shorter); the second number is the value supplied by the requesting crc
argument, defaulting to 0.
The chunk end line looks like #####REPLAY_CHUNK_END#####
and is also terminated by a CRLF.
The end of a file seems to be signalled by a chunk start line with no chunk end line, as the full contents of an HTTP response body.
-- ToddLarason - 31 Mar 2002
Topic IvsProtocol . { Edit | Attach | Ref-By | Printable | Diffs | r1.5 | > | r1.4 | > | r1.3 | More } |
Revision r1.5 - 01 Apr 2003 - 04:44 GMT - TWikiGuest |
Copyright © 2001 by the contributing authors.
All material on this collaboration tool is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |