Home Help Center

How to reduce round trip delay?

andreynechandreynech Member Andrey NechypurenkoOrganization: Veterobot.comProject: Robotics vehicle for researchers and makers ✭✭
Hi Folks,

I am currently working on the video client and server applications. My idea was to use Ice for stream control and for transmitting video frames.

Client application (player) could be run from behind the firewall and I do not want to force the user to reconfigure firewall or run any additional applications such as Glacier. For this reasons, I assume that it is not possible to call player back from the server. That is why, the only way for the client to get new frame is to actively request it using interface like this:

interface VideoSource {
void getNextFrame(out sequence<byte> frame);
}

It works great in LAN. However, over the Internet, the delay between frames is unacceptable.

I believe that delay is caused by the need to send function request to the server for each frame. I was trying to run communication and frame processing (decoding and displaying) in different threads but it seams like decoding and displaying is much faster then communication delay, so this strategy does not bring a lot.

Finally, I've re-implemented frame transmission using raw sockets. Client opens connection to the server and read() incoming frames. At the server side, as soon as the new frame is available, the server write() frames to the existing connection. As a result, there is no "request" from the client for each frame. This strategy leads to the acceptable performance.

Despite good performance, I do not like this solutions for various reasons such as additional complexity to support SSL, proper handling of sudden connection breaks and re-connections, eventually additional libraries and technologies for portability, etc. So I would prefer to perform all communication with Ice.

I would really appreciate if somebody can suggest the implementation strategy with Ice which can eliminate round-trip delay considering restrictions (firewall) mentioned above.


Thank you,
Andrey.

Comments

  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Please have a look at the article "Optimizing Performance of File Transfers" in issue 20 of our newsletter Connections. This article is about file transfer, but the implementation strategies apply to any kind of data transfer, including video transfer.
  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Client application (player) could be run from behind the firewall and I do not want to force the user to reconfigure firewall or run any additional applications such as Glacier. For this reasons, I assume that it is not possible to call player back from the server

    You need run Glacier2 in server side not in client side Ice Run Time can reuse the connection open to Glacier2 to call the Player. See the Chat examples in Newsletter for examples of how do this.
    Hope this help
  • andreynechandreynech Member Andrey NechypurenkoOrganization: Veterobot.comProject: Robotics vehicle for researchers and makers ✭✭
    Hi Marc,

    Thank you for the quick response.
    marc wrote: »
    Please have a look at the article "Optimizing Performance of File Transfers" in issue 20 of our newsletter Connections. This article is about file transfer, but the implementation strategies apply to any kind of data transfer, including video transfer.

    I was aware about this article. The core idea for the client there is to use AMI. Since I was experimenting with multiple threads essentially simulating AMI without big improvement (since decoding and displaying is fast) I concluded that AMI would not help me either. However after reading the article once again I realize that there is possibility to have multiple AMI invocations as described in the example. It might be helpful for my situation also. Thank you for the hint!

    One brief question about AMI - will the server try to open new connection to deliver the result to client or will the existing connection between client and server be used?

    Thank you very much,
    Andrey.
  • andreynechandreynech Member Andrey NechypurenkoOrganization: Veterobot.comProject: Robotics vehicle for researchers and makers ✭✭
    xdm wrote: »
    You need run Glacier2 in server side not in client side Ice Run Time can reuse the connection open to Glacier2 to call the Player. See the Chat examples in Newsletter for examples of how do this.
    Hope this help

    Wow, I did not realize that such possibility exists. I definitely need to read Connection issues more carefully :-) . Thank you very much for the hint!
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    andreynech wrote: »
    One brief question about AMI - will the server try to open new connection to deliver the result to client or will the existing connection between client and server be used?

    AMI is not different in its connection use from regular twoway calls, i.e., request and response are sent over the same connection.
  • andreynechandreynech Member Andrey NechypurenkoOrganization: Veterobot.comProject: Robotics vehicle for researchers and makers ✭✭
    marc wrote: »
    AMI is not different in its connection use from regular twoway calls, i.e., request and response are sent over the same connection.

    Thank you Marc for the information!

    I think in my case it would be more efficient to implement the callback mechanism with Glacier2 as suggested by Jose (aka xdm) because then there would not be frame requests from player to server at all in contrast to AMI-based solution. It is is almost the same as with my raw socket implementation and I hope that performance will also be similar. Somehow I've overlooked this nice feature of Glacie2 in the past.

    Once again thank you all for the information. I've learned again a bit more about Ice by this thread :)
Sign In or Register to comment.