Hi Adrian, Michiel, Ruud, Denis et al.<br><br>After I putted the pieces together as described earlier, I kept getting this error:<br><br><span style="font-family: courier new,monospace;">Traceback (most recent call last):</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "./21_sip_offer_desktop", line 85, in <module></span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> main()</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "./21_sip_offer_desktop", line 76, in main</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> vncserver(SockInt4MSRP(session))</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/home/willem/sip/21/vncserver.py", line 42, in vncserver</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> sock2sock(x11sock, clientsock)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/home/willem/sip/21/vncserver.py", line 36, in sock2sock</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> data = data[sock2.send(data):]</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/home/willem/sip/21/sockint4msrp.py", line 24, in send</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> msrp.send_message(data, content_type)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/msrplib/transport.py", line 448, in send_message</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> self.send_chunk(chunk)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/msrplib/transport.py", line 364, in send_chunk</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> self.write_chunk(chunk)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/msrplib/transport.py", line 220, in write_chunk</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> self.write(chunk.encode())</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/msrplib/transport.py", line 216, in write</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> return self.transport.write(data)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/twisted/internet/abstract.py", line 182, in write</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> self.producer.pauseProducing()</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/eventlet-0.9pre-py2.5.egg/eventlet/twistedutil/protocol.py", line 43, in pauseProducing</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> self.event.reset()</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> File "/usr/lib/python2.5/site-packages/eventlet-0.9pre-py2.5.egg/eventlet/coros.py", line 110, in reset</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> assert self._result is not NOT_USED, 'Trying to re-reset() a fresh event.'</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">AssertionError: Trying to re-reset() a fresh event.</span><br>
<br>Looking at <span style="font-family: courier new,monospace;">twisted/internet/abstract.py</span> I saw that everything written is buffered and that the producer is paused when the buffer is full. The producer is in our case the process reading from the vncserver and writing to the msrp transport. Only nothing was actually paused. The send_message method, always returns immediatly.<br>
I've tried several things (like testing for the buffersize, and then waiting for a while until the buffer would shrink again), but I finaly concluded that <br><br>The write method of class MSRPTransport in file msrplib/transport.py<br>
<br><span style="font-family: courier new,monospace;"> def write(self, data):</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> if self.traffic_logger:</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> self.traffic_logger.report_out(data, self.transport)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> return self.transport.write(data)</span><br>
<br>should be altered to:<br><br><span style="font-family: courier new,monospace;"> def write(self, data):</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> if self.traffic_logger:</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> self.traffic_logger.report_out(data, self.transport)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> GreenTransportBase.write(self, data)</span><br>
<br>as the baseclass GreenTransportBase, <b>does</b> implement a mechanism in which it can be paused by twisted calling the <span style="font-family: courier new,monospace;">pauseProducing</span> function. Also the write method of the <span style="font-family: courier new,monospace;">transport</span> object, currently a <span style="font-family: courier new,monospace;">FileDescriptor</span> class from twisted/internet/abstract.py, doesn't return anything, so I don't understand why the <span style="font-family: courier new,monospace;">MSRPTransport</span> class returns the returned value from the method.<br>
<br>After making the proposed alteration, the vncserver and client connected succesfully, but after a while, garbage is written the the viewer. In the vncserver log it mentions the creation of a xdamage object, and shortly afterward mentions the resetting of the connection by the client.<br>
I suspect that the messages from the vncserver to the client might not arrive in the right order. I think the MSRP-relay just tries to sent out all messages it receives as quickly as possible. A short messages could arrive earlier then a big messages, even if the short message was sent after the big message. I should investigate this further to be sure... but how?.<br>
Increasing the message size of the server does work (maybe because all the related RFB messages then are more likely to stick together), but the performance in the viewer is then extremely poor. Screen updates take tens of seconds.<br>
<br>When using <span style="font-family: courier new,monospace;">MSRPTransport.deliver_message</span> in stead of <span style="font-family: courier new,monospace;">send_message</span>, the performance is much better! Small updates take only 3 seconds or less, but big update still take tens of seconds. I'm under the impression that smaller message sizes perform better with <span style="font-family: courier new,monospace;">deliver_message</span> then big message sizes, but it doesn't differ much. It is still unusably slow.<br>
I understand (from reading the source) that <span style="font-family: courier new,monospace;">deliver_message</span> only checks the first hop, and doesn't actually guarantee that the message are actually delivered. Perhaps waiting for this answer just slows down the process so much, so that messages are able to arrive in the right order.<br>
<br>It is also interesting to see how x11vnc adjust its estimated link rate. Only with <span style="font-family: courier new,monospace;">deliver_message</span> it estimates it to slower than LAN speed. Maybe x11vnc adjusts its update alogrithm to the link speed.<br>
<br>I think ideally with RFB over MSRP we would like to use <span style="font-family: courier new,monospace;">send_message</span>, in stead of <span style="font-family: courier new,monospace;">deliver_message</span>. We do not need to be confirmed of the message being deliverd at the MSRP-Relay. We do however like te be able to process the next message only as the previous one is sent out over the tcp connection. Even with the altered <span style="font-family: courier new,monospace;">write</span> method, <span style="font-family: courier new,monospace;">send_message</span> still doesn't allow this. The <span style="font-family: courier new,monospace;">transport</span> object (from twisted) seems to use a buffering mechanism with a seperate threat actually sending out all the messages.<br>
<br>I understand that the usage of those twisted classes will give better performance at an instant-messaging-user-interface. The control is directly returned to the process displaying and inputting messages, without waiting for the old message being sent out, but for a regular tcp session this is not ideal.<br>
<br>I see another problem with TCP sessions over MSRP in general. With regular TCP an answer to a message can be returned with the confirmation of the reception of the message. With MSRP this is not possible. MSRP acts as two unidirectional streams which are guaranteed to be delivered, but the connection between the reception of a message and the response is not there anymore. This is no problem with streams that have a 'command, reply' structure (such as smtp, pop, http etc), but it is a problem when there is a stream of messages and a answer should be able to be sent back with the acknowlegment of a specific message from that stream. Such a message, when tunneling over MSRP, could be received at a much later time.<br>
I'm not under the impression that this is a problem with the RFB protocol, but I can imagine that a better update mechanism could be chosen by the vncserver when it has a realistic idea of how quickly its messages are received by the client. At the moment it seems to estimate this on the basis of the time it takes to actually sent out a message (which we can't because of twisted buffering). An implementation using a TURN server would also have this problem: The vncserver would then estimate its speed as the speed it takes for the TURN server to receive the messages.<br>
<br>The scripts I have been testing with are attached in sip_desktop_sharing.tgz.<br><br>I'm beginning to feel that we should drop trying to tunnel RFB over MSRP, and in stead should try to set it up as a regular TCP session between end-points as described in <a href="http://www.netlab.tkk.fi/%7Ejo/papers/draft-garcia-mmusic-sdp-collaboration-00.txt">draft-garcia-mmusic-sdp-collaboration-00</a>. End-points could be using a STUN or TURN server to travese the NAT if neccesary, based on procedures described in <a href="http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-07">draft-ietf-mmusic-ice-tcp-07</a> .<br>
<br>For the moment I think I would like to investigate a VNC server which let you pick an application window to share (in stead of the whole desktop (as with <a href="http://shared-app-vnc.sourceforge.net/">SharedAppVNC</a>) ). I would also like to try to get sipsimpleclient running on MS-Windows.<br>
It would be nice to try the attached scripts with an <span style="font-family: courier new,monospace;">MSRPTransport.send_message</span> that returns when the message is actually sent over TCP. Would any of you be able to implement such a function?<br>
After that, I should start on writing the report, as time is running out.<br><br>Cheers,<br><br>Willem<br><br>