Forum Discussion
albert_forster_
Nimbostratus
Nimbostratusrelate_client & relate_server
We use TCP::collect and TCP::payload to gather the initial OPTIONS command. Then use TCP::respond to send an options response back to the client. With TCP::collect and TCP::payload we get the DESCRIBE request from the client. A TCP::release to send the DESCRIBE request (data from TCP::collect) to the server. The DESCRIBE is answered (RTSP OK) by the server.
Obviously no UDP connection can be established, so the client sends a TEARDOWN request after a timeout. For the proposed relate_client/relate_server commands no documantion can be found, so we don't even know the syntax.
Furthermore it seems, that the TCP::respond triggers a TCP::release and sends the OPTIONS command to the server, so the client receives two RTSP OK responds (one from TCP::respond and one from the server), both with CSeq: 1.
when CLIENT_ACCEPTED {
set i 0
TCP::collect
}
when CLIENT_DATA {
if { [TCP::payload] contains "CSeq: 1" and $i < 1}
{
set i 1
TCP::respond "RTSP/1.0 200 OK\r
CSeq: 1\r
Date: Mon, 04 Apr 2005 11:15:56 GMT\r
Server: Helix Mobile Server Version 10.0.5.1621 (sunos-5.8-sparc-server) (RealServer compatible)\r
Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN\r
RealChallenge1: 162a2d05500ae08260f6c0cb21e37855\r
StatsMask: 7\r
\r
"
TCP::collect
}
if { [TCP::payload] contains "transid" }
{
set desc [findstr [TCP::payload] "transid" 8 7]
log "desc: $desc"
TCP::release
}
}
- I performed a simple test and was unable to reproduce any problems with TCP::response triggering a release. Additionally, the TCP::collect in CLIENT_DATA is also unnecessary since you already set TCP::collect in CLIENT_ACCEPTED; however, that does not trigger a release either.
Here is the syntax of the relate command. This command was not documented because quite honestly, we didn't imagine anyone wanting to use it except us.relate_{client|server} { proto clientflow serverflow } - I think the problem with the OPTIONS command is that the command is still in the buffer. So, when you do eventually get the "transid" string, both the OPTIONS and the DESCRIBE end up going to the server.
What you likely will want to do is remove the OPTIONS command after you have responded. You can do this with a command like:TCP::payload replace ""
offset and length indicate the location to replace with the empty string. You may be able to simply throw away the entire payload at the point you determined it was an OPTIONS command. That can be done with:TCP::payload replace 0 [TCP::payload length] "" - BTW, Dr.Teeth's comments about the TCP::collect/TCP::release might seem confusing, so here's some further notes about the TCP::collect & TCP::release commands:
There are several implicit rules that are probably worth mentioning regarding the CLIENT_DATA/SERVER_DATA events.
1) If TCP::collect is specified with no arguments, it is considered an indefinite hold. New incoming data will continuously be aggregated in the payload and trigger CLIENT_DATA/SERVER_DATA events until an explicit TCP::release is given. If TCP::release is used with an argument, the indefinite hold will continue and only the specified amount of data is released. If TCP::release is used without arguments, the entire payload is released and the indefinite hold is cancelled.
2) There is an implied TCP::release at the end of the CLIENT_DATA/SERVER_DATA event if TCP::collect was specified with an explicit amount. This implied release can be overriden with an explicit TCP::release command or a new TCP::collect command in the event.
So, Dr.Teeth's remark about the additional TCP::collect is due to the fact that the original TCP::collect in CLIENT_ACCEPTED was an indefinite hold. However, it also does not adversely effect anything having the extra TCP::collect in there.
Hope this helps. 
Yepher_100160Does anyone have any idea how to use "relate_client" and "relate_server"?
Could I use this to bridge two TCP clients together?
