Question

I am creating a client server app to stream images contiguously to work like a video streaming application.

The client app is having a timer which ticks for every 300 ms to send request to the server and the server replies with the image.

The implementation works ok , but after some time ( ~ after 5 minutes or more ) both the apps get freeze without any error messages (but very very rarely i get a message saying out of system resource )

This was even worse before (freezes after ~ 15 seconds ) but i changed the idtcpserver1.terminatewaittime to 10 (from 5000 defalt) now it happens after 5 minutes.

I can't understand why the error is happening but i am quite sure it is not good to use timer based request.

can i convert the tcpserver into unreliable connectionless protocol to make it faster and reduce the request stress.

But i don't want to use UDP as it can't detect corruption error (But i don't need correction , i only want to know is there any error(to ignore the whole image))

procedure server.IdTCPServer1Execute(AContext: TIdContext);
begin
LLine := AContext.Connection.IOHandler.ReadLn();
AContext.Connection.IOHandler.Write(ast, 0, true);
end;

procedure client.timertick(Sender: TObject);
begin
IdTCPClient1.IOHandler.WriteLn(Edit1.Text);
LLine := TMemoryStream.Create;
IdTCPClient1.IOHandler.ReadStream(LLine, -1, false);
end;

only source code relevant to Indy are given others are withheld

=============== updated After Remy Lebeau - TeamB and Arnaud Bouchez Answers ==========

Thanks the freezing is caused because of inaccessibly of image in certain situations. The tools mentioned by them helped me to track down the problem

But still the main problem is not solved

can i convert the tcpserver into unreliable connectionless protocol to make it faster and reduce the request stress.

Was it helpful?

Solution

The timertick code you have shown as memory leaks. You are not freeing the TMemoryStream that you create, which in turn leaks any memory that the stream allocates internally.

The TerminateWaitTimeout property has no effect on the runtime behavior of connections. It is only used when shutting down the server, to specify how long the server waits for active connections to terminate.

TCP is not well-suited to streaming media, and using a command/response to grab images is inharently slow. At least get rid of the commands in between frames and just send the frames whenever they are available. TCP can handle that. Most audio/video streaming apps are based on UDP to avoid unnecessary overhead that TCP uses, however.

OTHER TIPS

You have a resource leak.

Perhaps you are not freeing your network resources, or an GDI resource.

  • First is to run ProcessExplorer then look at how many handle your application is creating, and how many connections are created;
  • Then launch FastMM4 in memory leak detection mode;
  • If your resources are not mapped with Delphi classes, try to find in your code how they are allocated / released (using Find IDE command with API call names);
  • It may be related to a threading issue - perhaps some kind of race condition - try to lock your shared resources;
  • Use a logging mechanism to trace what is happening in your process, especially about all Indy classes;
  • See other hints in this StackOverflow answer.

What is interesting with UDP is that you can broadcast your stream to multiple targets at once. Potential packets loss is balanced by decreased bandwidth use, in case of client number increase. Worth looking into that direction if you need local broadcast with limited resource use (but will be more complicated over the Internet).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top