What protocol i have to adopt for reliable transmission?

[cartographer]

Hi all,

I have devloped a Remote Managment App. where server captures the
updated regions of its screen and sends to client.

Problem is that server captures the area which is updated and then
sends. Updation is so frequent and so quick if i will try to send
all the updates as they occur then i think evrything will stop.

So i stores the updates info into a queue and then get them one by one
and sends to client. It looks all will be fine but after some data
tranfer my client stops receiving data. Why i dont know?

What protocol i have to use to make my session a reiable one and
to minimize memory usage by removing intermediate queue?

Thanx

[harshandu]

Hello,

I suggest to go on for the TCP/IP protocol.Its better to create two threads one for capturing data and another for sending data.Its better to use queues but addition to that a synchronization mechanism is to be established between the two threads over the queue.This can be done by using the synchronization tool semaphore or counting semaphore.

[cartographer]

U r quite right but we need our own properietry standard.
Actualluy i m using system wide hooking dll to hook into
the address space of each running process. That dll captures
all the messages sent to these processes by OS and post the
messages related to screen updates to my server application.
Each message contains area of the updated rectangle. My server
application gets the messages posted my dll.

If i dont use queue to store all messages posted to my server
by my dll then i may loss ceratin messages but if i use it then
my memory usage goes higher.

So in that situation what should i do.

[akgalp]

hooking on to appln to know abt the screen updates will use lot of system resource , using a buffer , and checking with the prev capture may be faster and managable.

[Mathew Joy]

Frequent updates, each update small in size (my guess) and the updates should reach the client. With frequent update of one thing, you can afford to loose some update since the next update will have a recent information, provided the information is absolute not relative to the previous update. You can use the underlying protocol as UDP, though unreliable, it is faster and light. Only thing to keep in mind is discard duplicate and out of ordered packet that arrive at the client side.

[cartographer]

I m not asking about the standard communication protocol.
Actually i want to write down my own protocol that allows
the server to get update messages from its message queue
posted by the dll. The server then captures the region of the
screen identified by the message and send client the region's
dimensions + region data in compressed form. Client receives
the dims and data and then draws the region in its appropriate
position.

Either my server should wait for acknowledgement of the client
ready signal for next update or send next region consecutively.

There is problem here somewhere exception happens in client
and connection is terminated.

[Mathew Joy]

I was talking about this part

...send client the region's
dimensions + region data in compressed form. Client receives
the dims and data and then draws the region in its appropriate
position.

Either my server should wait for acknowledgement of the client
ready signal for next update or send next region consecutively.

Why do you go for a new transmission protocol when you have standard ones that suit your needs? It will be re-inventing the wheel.

[cartographer]

I need help regarding to negotiating protocol.
What messages server/client should send and receive.
When server should send the regions(rectangle) to the
client?

I think its more important and difficult for me then making
a hooking dll and capturing regions bcz i m not so strong
in making a protocol( a reliable).

[Mathew Joy]

That was exactly what I am saying. Selecting UDP or TCP is not the end of story. But that is the first. You need to build a application protocol on it(UDP/TCP). But the first part is select which transport layer protocol. My suggestion was UDP and I've given the reasons. If you can't agree with that we can discuss the pros and cons. UDP is unreliable but it is fast. Since we are using frequent updates a bit of loss is OK. If we need few packet of reliable service, we can either use TCP connection in parellel or use some ACK for those few packets. I hope you are getting the picture.