I am creating a simple server application, that will listen for
incoming mouse coordinates and then move the mouse accordingly. So
basically it's like a very simple VNC server without and screen
display. I have this basic part working. The problem is that response
time is really bad. It seems like the server is not receiving the data
fast enough to be able to move the mouse so that it appears to be in
sync with the movement on the client machine. I'm using a buffer size
of 32, and just sending my commands from the client as the same length
every time. When they come in, I add them to a queue, then have a
separate thread that processes the movement in the queue as it comes
in. I figured this was the fastest way, but it doesn't seem to be fast
enough. Clearly there is a better way of doing this that I'm not
seeing. Any suggestions?

My code looks something like this:

Public Sub dataArrival(ByVal ar As IAsyncResult)

Dim bytesRead As Integer = handler.EndReceive(ar)

If bytesRead 0 Then

content = Encoding.ASCII.GetString(state.buffer, 0,
bytesRead)

eventQueue.Add(content)

handler.BeginReceive(state.buffer, 0,
StateObject.BufferSize, 0, New AsyncCallback(AddressOf dataArrival),
state)

end if

end sub

I suspect that the problem may be a delay in the sending code, not the
receive code. Does anything look suspicious there?

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

The sending code is written in C because it's cross platform. Anytime
there is mouse movement, it simply calls the following code with a
string like "x=100,y=200"

send(sockfd, [data bytes], [data length], 0);

I've tried sampling the mouse movement at different intervals, but
doing it too slow gets choppy movement, and doing it at an appropriate
rate seems to send data faster than it can reach the server in time to
be processed in what would appear as realtime to the user. This is
always run over a LAN, so I don't see how I could possibly be sending
too much data. How can I tell exactly where the delay is?


On Aug 11, 2:39*pm, "Dick Grier" <dick_grierNOSPAM@.msn.comwrote:

I suspect that the problem may be a delay in the sending code, not the
receive code. *Does anything look suspicious there?
>
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.

The sending code is written in C because it's cross platform. Anytime
there is mouse movement, it simply calls the following code with a
string like "x=100,y=200"

send(sockfd, [data bytes], [data length], 0);

I've tried sampling the mouse movement at different intervals, but
doing it too slow gets choppy movement, and doing it at an appropriate
rate seems to send data faster than it can reach the server in time to
be processed in what would appear as realtime to the user. This is
always run over a LAN so I can't see how I could be sending too much
data. How can I tell exactly where the delay is?


On Aug 11, 2:39*pm, "Dick Grier" <dick_grierNOSPAM@.msn.comwrote:

I suspect that the problem may be a delay in the sending code, not the
receive code. *Does anything look suspicious there?
>
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.

Hi,

There is significant latency in TCP/IP (especially if a wireless connection
is involved). I try to match my sending data size to the actual TCP/IP
packet size, to minimize this. Natrually, this is not practical in your
case. Adding the data to a queue adds additional latency on the consuming
side (IMO, I'd just process it directly).

Perhaps you should try to use UDP instead of TCP. UDP isn't connection
orriented, so it has much lower inherent latencies.

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

Hi,

There is significant latency in TCP/IP (especially if a wireless connection
is involved). I try to match my sending data size to the actual TCP/IP
packet size, to minimize this. Natrually, this is not practical in your
case. Adding the data to a queue adds additional latency on the consuming
side (IMO, I'd just process it directly).

Perhaps you should try to use UDP instead of TCP. UDP isn't connection
orriented, so it has much lower inherent latencies.

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.