2

I have a ASP.NET server app that uses SignalR. I have an HTML5 client. The server sends a small byte array (around 12k) JPEG to my client, which receives and displays the image in an IMG element.

The frequency of the data sent to the client(s) is erratic, and I am concerned about overload. At the moment I use timer control to relay messages from server at regular intervals. For desktop browsers using a dedicated broadband connection everything works smoothly, however if I use a mobile device browser the mobile can take longer to load an image for whatever reason (like poor internet connection and/or low power supply on the battery).

Ideally, I would like my client(s) to send an acknowledgement to my server to 'say' the image has been loaded OK and I am ready to receive the next one. I could facilitate the received notification either through a signal client method or say an API call.

I am worried about 2 things:

  • Unnecessary overhead from headers (etc) from client to server call

  • Negating the benefits of using SignalR

I am strongly leaning to just relying on timers in server controls and increasing the 'timeout' for mobile devices but I am open to ideas. Has anyone else encountered this type of scenario and if so have a different approach?

08Dc91wk
  • 4,254
  • 8
  • 34
  • 67
Andrew Simpson
  • 6,883
  • 11
  • 79
  • 179

1 Answers1

3

Try the approach documented in this answer.

Summary: Assign each JPEG an ID. When the client is ready for the next image have it report the ID of the last image loaded so that the server knows which image to send next.

Community
  • 1
  • 1
Oren Hizkiya
  • 4,420
  • 2
  • 23
  • 33
  • 1
    Hi Owen, good of you to propose a solution. The problem is that the server sends 12kb to my client (each time). If the client is still loading an image (I check in the img.onload and img.onerror events) then it will not load the next image and skip it. That is fine. But, what I am trying to do is not send that 12kb byte array to the client in the 1st place as it wastes time and bandwidth.. – Andrew Simpson Jan 04 '15 at 16:38
  • 2
    The alternative in that case is to first broadcast that a new image is available and then have the client indicate whether it is ready for the next image. I am not sure this optimization is necessary, since it would require a full round trip for the sake of saving 12kb but you would have to benchmark it based on the anticipated frequency of images that you would like to publish. – Oren Hizkiya Jan 04 '15 at 16:43
  • Exactly, that is my problem/dilemma. The solution at the moment I have is favored towards is frequency with no round-robin trip and potential waste of data sent.. Just curious to know what my peers here think. Thank you :) – Andrew Simpson Jan 04 '15 at 16:45