I'm coding a network utility to share the mouse and keyboard between two Amiga OS4 machines.

As such I need to send messages back and forth between the machines in a timely fashion and in fact it's working rather well *most* of the time, but I'm seeing two issues.

1. If I have to interupt and restart the server, the I see that the listen socket hangs arround arround for more than a minute after I closed it down. Is this normal? It means the server can't be restarted, as it can't bind to the port number. This is largely only a problem when testing as when running for real the server would rarely need a restart, but I want to be sure that I'm not missing something in the shutdown procedure. I'm closing the socket with ISocket->CloseSocket() and ofcourse I close bsdsocket.library at prpgram exit. (Note this is not an inetd style server so it';s not the inted thing holding the scocket open).

2. This is the more complex one I think:

90% or more of the time the return trip of the server sending a command to and getting a response from the client takes at most 50ms most oftem much less. This allows quite smooth operation of the mouse on the remote (client) machine. Every now and again though I'm getting amassive delay of more than 1300 ms this causes quite a stutter in the mouse as you might imagine.

I'm trying work out why this is happening, and have added lots of timing debug, it seems to me to be that the delay is at the network level.

My packets of info are short eg "RAWMOUSE %hu %hu %hd %hd" but it seems occasionaly the client has to wait up a second to recieve the packet (and this is across the LAN ).

Some simplified code:

Server SendMsg() code:

        struct TimeVal tv;

        tv.Seconds = 2;
        tv.Microseconds  = 0;
        int n = 0;
        if((n = ISocket->WaitSelect(FD_SETSIZE,NULL,&writefds,NULL,&tv,NULL)) != -1)
        {

                if(n > 0)
                {
                        if(     ISocket->send(sock,(APTR)msg,strlen(msg) + 1,0) == -1)
                        {
                                DropClient(server,sock);
                                return FALSE;
                        }
                }
                else
                {
                        /* Timeout increment dropped packets */
                        printf("Send Timeout\n");
                        DropClient(server, sock);
                        return FALSE;
                }
        }
        else
        {
                printf("WaitSelect error %s %d\n",__FUNCTION__,__LINE__);
                return FALSE;
        }

        /* autodoc says not to assume timevalue unchnaged so reset */
        tv.Seconds = 2;
        tv.Microseconds  = 0;

        if((n = ISocket->WaitSelect(FD_SETSIZE,&readfds,NULL,NULL,&tv,NULL)) != -1)
        {

                if(n > 0)
                {
                        TEXT buffer[512];
                        if(     ISocket->recv(sock,buffer,sizeof(buffer),0) == -1)
                        {
                                DropClient(server,sock);
                                return FALSE;
                        }
                        enum Protocols ID = IdentifyProtocol(buffer);

                        switch(ID)
                        {

                        ...
                        ...
                        ...
                        Code Handleing response here
                        ...
                        ...
                        ...

                        }
                }
                else
                {
                        /* Timeout increment dropped packets */
                        printf("Receive Timeout respoe to %s\n",msg);
                        DropClient(server,sock);
                        return FALSE;
                }
        }
        else
        {
                printf("WaitSelect error %s %d\n",__FUNCTION__,__LINE__);
                return FALSE;
        }
       return TRUE;

}

while(alive)
{
   fd_set readfds;
   FD_ZERO(&readfds);
   FD_SET(sock,&readfds);
   struct TimeVal tv;
   tv.Seconds = 4;
   tv.Microseconds = 0;

   int n = 0;
   if((n = ISocket->WaitSelect(1,&readfds,NULL,NULL,&tv,NULL)) != -1)
   {

           if(n > 0)
           {
                   int len;
                   if((len = ISocket->recv(sock,buffer,sizeof(buffer) -1,0)) > 0)
                   {


                           buffer[len] = 0;
                           enum Protocols ID = IdentifyProtocol(buffer);
                           switch(ID)
                           {
                                   case RAWKEY:
                                   {
                                           SendResponse(sock,(APTR)RECEIVED_MSG,strlen(RECEIVED_MSG) + 1);

                                           /* Do stuff include input.device IO */
                                           break
                                   }
                                   ...
                                   ...
                                   ...
                                   ...
                                   Handle Other stuff
                                   ...
                                   ...
                                   ...
                           }
                   }
                   else
                   {
                           /*Could be Socket error or shutdown we don't care */
                           printf("sock error %ld\n",ISocket->Errno());
                           alive = 0;
                           reconnect = 1;
                   }
           }
           else
           {
                   /* Timeout */
                    printf("Connection time out\n");
                    alive = 0;
                    reconnect = 1;
           }
   }

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

1. If I have to interupt and restart the server, the I see that the listen socket hangs arround arround for more than a minute after I closed it down. Is this normal? It means the server can't be restarted, as it can't bind to the port number.

This is normal. You must set SO_REUSEADDR from setsockopt() call.

Quote:

90% or more of the time the return trip of the server sending a command to and getting a response from the client takes at most 50ms most oftem much less. This allows quite smooth operation of the mouse on the remote (client) machine. Every now and again though I'm getting amassive delay of more than 1300 ms this causes quite a stutter in the mouse as you might imagine.

You might want to disable Nagle algoritm. Try TCP_NODELAY from setsockopt() and see if it makes difference. By default TCP tries to reduce the number of packets sent over network and combines small send request to send them all at once.

Last edited by itix on 02-Sep-2014 at 04:10 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

Quote: @broadblues Quote: 1. If I have to interupt and restart the server, the I see that the listen socket hangs arround arround for more than a minute after I closed it down. Is this normal? It means the server can't be restarted, as it can't bind to the port number. This is normal. You must set SO_REUSEADDR from setsockopt() call.

Thanks I'll investigate that, although whilst testing I've noticed it shuts down more clweanly if the client exits first, so ther may be some lingering data on the server socket I need to deal with.

Quote:

Quote: Quote: 90% or more of the time the return trip of the server sending a command to and getting a response from the client takes at most 50ms most oftem much less. This allows quite smooth operation of the mouse on the remote (client) machine. Every now and again though I'm getting amassive delay of more than 1300 ms this causes quite a stutter in the mouse as you might imagine. You might want to disable Nagle algoritm. Try TCP_NODELAY from setsockopt() and see if it makes difference. By default TCP tries to reduce the number of packets sent over network and combines small send request to send them all at once.

I tried this but it didn't seem to affect the behaviour.

I set TCP_NODELAY on both the server accept socket and clients connected socket.

I used the call like so:

int on = 1;
if(setsockopts(sock,IPPROTO_TCP,TCP_NODELAY,&on sizeof(on)))
{
printf("Error setting TC_NODELAY\n");
}

the other example I found on the net used SOL_TCP instead of IPPROT_TCP but SOL_TCP doesn't appeared to be defined in the bsdsocket includes.

I got noe error report so I assume it worked, but it didn't affect the behaviour.

I've added extra debug to track the individual events and so can see the pause occurs between the send() on the server side and the unblocking od WaitSelect() on the client side.

Server side:
Timer is reset before first waitselect()

SendMsg sock 1 RAWMOUSE 255 32768 3 3 1327  7154928447481
line 140 1  (after writefd waitslect)
line 150 2  (after send() )
line 173 5  (after readfd waitslect)
leaving SendMsg sock 1 RAWMOUSE 255 32768 3 3 1327  7154932925036 6
SendMsg sock 1 RAWMOUSE 255 32768 4 2 1328  7154933511591
line 140 1   (after writefd waitselect)
line 150 2   (after send)                            **********
line 173 1127 (after readfd waitselect)
leaving SendMsg sock 1 RAWMOUSE 255 32768 4 2 1328  7155760415231 1127

line 278 10                                (after readfds WaitSelect)
line 285 10 RAWMOUSE 255 32768 3 3 1327    (after recv)
line 337 11 RAWMOUSE 255 32768 3 3 1327    (after input devce io)
line 358 12 RAWMOUSE 255 32768 3 3 1327    (after send resposnse)
line 278 1126                              (after readfs waitSelect) *******
line 285 1126 RAWMOUSE 255 32768 4 2 1328  (after recv)
line 337 1127 RAWMOUSE 255 32768 4 2 1328  (after input device io)
line 358 1128 RAWMOUSE 255 32768 4 2 1328  (after send response) 

Last edited by broadblues on 02-Sep-2014 at 10:21 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

Thanks I'll investigate that, although whilst testing I've noticed it shuts down more clweanly if the client exits first, so ther may be some lingering data on the server socket I need to deal with.

Yes after checking I relealised when the server sent the BYE messeage to th client, the client was sending an aknowledgement that the sever didn't read, resulting in left over data on the socket. Tidied that up and both server and client exit cleanly.

So Issue 1 solved.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

While probably usable in itself, it would be an awful lot more useful if it would be compatible with synergy.

Just saying

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@broadblues

If TCP_NODELAY is not helping you are going to need network analyzer. Try tcpdump or if you want more sophisitcated you could run some simple client on Windows (for example) and analyze packets with Wireshark.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@olegil

Quote:

olegil wrote: @broadblues While probably usable in itself, it would be an awful lot more useful if it would be compatible with synergy. Just saying

I used Synergy a lot when i had little space and i couldn't put another mouse/keyboard for the Amiga on the PC's table:
Synergy Client for AOS4
Another small GUI for it

_________________
Proud Amigan since 1987
Owner of various Commodore and a SAM440ep\OS4.1FE
See them on http://retro.furinkan.org/

@olegil

Synergy would need to be made amiga compatable for that to happen, for example it does now know the difference between a left and right amiga key, it just sends 'command key' mac style (probably because I was running the server on a mac). We have a version that sort of works between mac/pc and amiga. what we don't have is amiga to amiga which broadblues is writing but without all the synergy bloat...

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@olegil

Quote:

@broadblues While probably usable in itself, it would be an awful lot more useful if it would be compatible with synergy. Just saying

My initial idea was to port the synergy server, but after a birief look at the code (loads of c++) and build system (Cmake scripts writen very strictly with the assumption that only macs, linux and windows exist), I decided to write something abit leaner and more amigacentric.

I might backport the client at least to 3.x maybe even AROS / MOS (though I lack developement environments for that lattter two).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@itix

I'll look tcpdump up.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Found tcpdump, comes as standard with roadshow, did some logging at both ends and I see that the delay is caused a dropped packet and a TCP retry, which reties after 1.5 secs or so, I caught one in each direction.

Can thsi be configured to a shorter interval? (Is that a good idea any way? )

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

broadblues wrote: @broadblues Found tcpdump, comes as standard with roadshow, did some logging at both ends and I see that the delay is caused a dropped packet and a TCP retry, which reties after 1.5 secs or so, I caught one in each direction. Can thsi be configured to a shorter interval? (Is that a good idea any way? )

No and no. In Roadshow this timeout cannot be changed, and changing it would not be a good idea either.

TCP retransmission timeouts are not predefined in the TCP/IP stack, they are calculated dynamically from the time it takes the sender to transmit a segment and receive an acknowledgement from the receiver (round trip time). The longer the transmission takes, the longer the sender will wait for the receiver to either acknowledge reception, or the timeout to elapse, after which the sender will retransmit the segment. Calculating a robust round trip time takes a while, so you might see overly long retransmission delays on a "fresh" connection.

Tweaking the retransmission timeout would not be a good idea because you're bound to affect how the TCP/IP stack deals with network congestion. The TCP/IP stack considers dropped packets to be a sign of network congestion, and will scale back the rate at which it transmits packets.

The reason why the packet was dropped may be congestion, but it could also be any other reason unrelated to network traffic volume. Should you tweak the retransmission timeout, you might end up changing the TCP/IP stack strategy for dealing with congestion, and that strategy is already optimized to handle one specific problem scenario. You might end up making it more cautious (reducing your throughput), you might end up making it less cautious (temporarily increasing your throughput, and end up dropping packets due to congestion after all, reducing your throughput).

How serious is the dropped packet issue? At least the data is retransmitted at some point, and 1.5 seconds are still reasonably good in terms of user input feedback delay (this could be a lot worse).

@olsen

Quote:

No and no. In Roadshow this timeout cannot be changed, and changing it would not be a good idea either.

I did quite a lot of background reading last night and fully understand what you're saying there.

Quote:

How serious is the dropped packet issue? At least the data is retransmitted at some point, and 1.5 seconds are still reasonably good in terms of user input feedback delay (this could be a lot worse).

Well the 'design goal' is to be able to use the keyboard and mouse exactly as if it were conected to the client machine. In between the packet drops this is pretty much the case, there no lag when dragging the screen windows etc. But the drops cause an uncomfortable stick and jump in the mouse in particular (they can also occur with keyboard events but the consequences are less noticable, when typeing).

In different session I've found the drop rate varies, from once every 20mins (hardly an issue) to 1 every minute or so, gets to be a bit annoying.

Still with the higher drop rate it's still a lot better than VNCing to a remote amiga. It's quite usable for window manipulation and icon clicking, but not so good for precise actions like drawing in a paint program, or playing a game.

I'm working with a wired ethernet connection, I don;t know if the drop rate is higher on wireless or not.

I'd like to come up with some strategies for reduding the drop rate / impact.

Ideas I've had (but not tested so far).

1. Reduce data rate.

My maximum packet size is only about 30 bytes, many smaller, IIUC the tcp header is about that size so shrinking the packet size can only do so much here, peak data rate is of the order 15Kbs (including tcp headers).

2. Reduce packet rate.

I tested by capture 1000 packets with tcpdump and mousing steadily on the client.

1000 packets (500 each way) took 6.5 seconds.

I could add a timer and agregate mouse movement events, experimentaion required to find the lowest frame rate that feels smooth.

3. or something else?

Last edited by broadblues on 04-Sep-2014 at 04:17 PM.
Last edited by broadblues on 04-Sep-2014 at 04:16 PM.
Last edited by broadblues on 04-Sep-2014 at 04:15 PM.
Last edited by broadblues on 04-Sep-2014 at 04:14 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

broadblues wrote: Quote: How serious is the dropped packet issue? At least the data is retransmitted at some point, and 1.5 seconds are still reasonably good in terms of user input feedback delay (this could be a lot worse). Well the 'design goal' is to be able to use the keyboard and mouse exactly as if it were conected to the client machine. In between the packet drops this is pretty much the case, there no lag when dragging the screen windows etc. But the drops cause an uncomfortable stick and jump in the mouse in particular (they can also occur with keyboard events but the consequences are less noticable, when typeing).

This is strange. Keyboard and mouse input requires low latency, but the overall amount of traffic should be rather low. Say, 60 events per second don't amount to much. Unless something else on the network is competing fiercely with your event traffic, or the transmission of these events generates sufficient CPU load on your system that normal GUI operations and program activity put it at a disadvantage. Amiga network operations consume CPU time, as DMA is unsupported for network data exchange.

Quote:

In different session I've found the drop rate varies, from once every 20mins (hardly an issue) to 1 every minute or so, gets to be a bit annoying.

My gut feeling is that you should investigate why the drops are so frequent. From my experience packet errors or drops are very rare in a LAN, unless the local traffic volume is so high that the switches/routers have to drop packets just to keep up.

Quote:

Still with the higher drop rate it's still a lot better than VNCing to a remote amiga. It's quite usable for window manipulation and icon clicking, but not so good for precise actions like drawing in a paint program, or playing a game. I'm working with a wired ethernet connection, I don;t know if the drop rate is higher on wireless or not.

Wireless transmission is more susceptible to interference, and you don't necessarily get to find out what is causing the trouble. If you live in a rural area, chances are that the medium is pretty well-saturated, and if one of your neighbours switches on his ageing microwave oven, there might be additional trouble

Quote:

I'd like to come up with some strategies for reduding the drop rate / impact. Ideas I've had (but not tested so far). 1. Reduce data rate. My maximum packet size is only about 30 bytes, many smaller, IIUC the tcp header is about that size so shrinking the packet size can only do so much here, peak data rate is of the order 15Kbs (including tcp headers). 2. Reduce packet rate. I tested by capture 1000 packets with tcpdump and mousing steadily on the client. 1000 packets (500 each way) took 6.5 seconds. I could add a timer and agregate mouse movement events, experimentaion required to find the lowest frame rate that feels smooth. 3. or something else?

I think you should work on minimizing the packet rate. The user cannot necessarily generate more than about 60 events per second. If you lump keyboard and mouse events together into a single protocol unit, you might have fewer than 30-40 packets per second that need to be sent.

Are you sending packets at a constant rate, or do you only transmit events if you find that the overall event state (keys pressed/depressed, mouse buttons pressed/depressed, mouse position deltas) has changed?

It seems to me that your immediate problem is with packet drops, and how TCP handles those.

My advice would be to investigate how the packet drops come about.

If you're really adventurous, you might want to investigate switching to UDP: you'd have to do your own state and packet drop management then, but this is a topic which is rather well-researched these days thanks to "Quake II" and beyond

@olsen

Wireless networks also incorporate an ack/retransmit on the ARP layer, with a MUCH shorter timeout. Otherwise it would be exceedingly bad at transferring data in noisy environments.

For LAN, a dropped packet really should not happen. Especially at the rates we're talking about here.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@broadblues

Way do you use TCP? Way not use UDP, do you need all packages to get received?
If you drop one Mouse coordinates, it should not big deal if you get on the next package.

TCP timeout is long in windows as well, there for when I need to some thing like that in windows, I checked if connection was open using ICMP first. Then connecting only if did get a ping. Or else program stops and waits for moon eclipse before giving up.

@olsen
Quote:

My gut feeling is that you should investigate why the drops are so frequent. From my experience packet errors or drops are very rare in a LAN, unless the local traffic volume is so high that the switches/routers have to drop packets just to keep up.

This reminds me about problem we experienced at work, some technician created a patched loop in a switch, resulting in package storm / broadcast storm in the network. With all the network activity the network came to a holt.

If he has a lot traffick it be good idea to inveteracies what type of traffick (wireshark), check caballing and replace poor quality hubs with quality switches, etc.

Last edited by NutsAboutAmiga on 05-Sep-2014 at 07:53 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 06:52 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 06:49 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 06:13 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 06:12 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@olegil

Quote:

Wireless networks also incorporate an ack/retransmit on the ARP layer

ARP is not a layer, its package used for DHCP negating, it does not have ack/retransmit thats TCP, ARP works by broadcast. Or maybe your thinking about ICMP the protocol used by Ping.

While ARP has time out its not in the package, its up to the DHCP client to implement it.

When you are taking about "Wireless networks" your taking about "Data Link" layer and the "Physical" layer. "Nic frames.", actually I'm not sure about wifi, but for Lan its pretty simple stuff.





Its funny but to charts don't agree where ICMP belongs Network later or Transport layer, its not always easy to fit protocols in ISO model. Any how it should be in transport layer I think. ARP clearly belong to the Network layer.

Last edited by NutsAboutAmiga on 05-Sep-2014 at 07:33 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 07:28 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 07:24 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 07:08 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 07:05 PM.
Last edited by NutsAboutAmiga on 05-Sep-2014 at 06:28 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@olegil

Quote:

olegil wrote: @olsen Wireless networks also incorporate an ack/retransmit on the ARP layer, with a MUCH shorter timeout. Otherwise it would be exceedingly bad at transferring data in noisy environments.

Interesting - I didn't know that

It certainly makes sense in that environment. I knew that the wireless MTU was larger than in IEEE 802.3, but the frames apparently carry more transport layer information, too (probably not unlike the VLAN tagging in Ethernet frames).

Now that I'm curious, I'd like to know which ARQ scheme IEEE 802.11 is using, and how it works.

Quote:

For LAN, a dropped packet really should not happen. Especially at the rates we're talking about here.

I really would like to know more about Andy's network setup. It's just not so easy any more to perform traffic monitoring in a setup which uses UTP links and switches without taps

Last edited by olsen on 06-Sep-2014 at 08:33 AM.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @broadblues Way do you use TCP? Way not use UDP, do you need all packages to get received? If you drop one Mouse coordinates, it should not big deal if you get on the next package. TCP timeout is long in windows as well, there for when I need to some thing like that in windows, I checked if connection was open using ICMP first. Then connecting only if did get a ping. Or else program stops and waits for moon eclipse before giving up.

It seems to me that Andy is trying to build the basic protocol and functionality first.

UDP might solve the TCP related issues, but Andy would have to make major changes to his protocol to either add ARQ or have the individual datagrams carry the entire current keyboard/mouse event state. With TCP the retransmission is basically a solved problem, but you have to put up with the timeouts.

It's doable, but probably will take a lot of experimentation to make it work. This is not the approach I would recommend if you have little experience with BSD sockets and the underlying technology yet (Andy?). However, if there is a project which will teach you a lot about this subject matter, this would be it.

Quote:

@olsen Quote: My gut feeling is that you should investigate why the drops are so frequent. From my experience packet errors or drops are very rare in a LAN, unless the local traffic volume is so high that the switches/routers have to drop packets just to keep up. This reminds me about problem we experienced at work, some technician created a patched loop in a switch, resulting in package storm / broadcast storm in the network. With all the network activity the network came to a holt.

I know what you mean, we had this at my company, too

Somebody had unplugged one of the older switches in one of the offices, replaced it with a new one (those 100 MBit/s switches made in the early 2000s, in particular their power supplies, did not age well) and plugged the Ethernet cables back in the wrong way, so that the switch was now connected to two different floor tanks at the same time, creating a loop.

Things started to get seriously weird at this point, because the big switch that connected all the offices reacted by partitioning the network. Which was the right thing to do, but we only knew in retrospect what had happened. To the untrained eye this looked like a general network breakdown which could have been caused by anything.

In the end somebody (that would be me) started checking the cabling in each office room (mind you, we're not a big operation, so the number of rooms to check is small), and I got lucky in the first room I visited.

This is not the same problem scenario as the one Andy is experiencing, though. In a partitioned network you experience total loss of connectivity, and just maybe wicked broadcast storms if the switch at fault has dropped into "I'd rather be a hub" mode. Most of the time Andy has a reliable network, with rare but (for the application) significant packet loss.

Last edited by olsen on 06-Sep-2014 at 08:33 AM.

@olsen

Quote:

This is strange. Keyboard and mouse input requires low latency, but the overall amount of traffic should be rather low. Say, 60 events per second don't amount to much. Unless something else on the network is competing fiercely with your event traffic, or the transmission of these events generates sufficient CPU load on your system that normal GUI operations and program activity put it at a disadvantage. Amiga network operations consume CPU time, as DMA is unsupported for network data exchange.

The peak event rate from the mouse is about 120 events a second as far as I can tell.

The network is mostly idle while I've been testing. Though I am alos using NetFS between the two machines, the packet drops don't coinicide with activity on the remote volume.

My overall network consists of a Billion Router/DSL Modem attached to the internet with 4 ethernet ports and wireless. I have a linux laptop attched wireless then the X1000 SAM and a linux/windows box attched vis ethernet cables. If I'm working on the amigas then the linux laptop is idle so not likely to be stressing the network. The other linux box has been unused during the majority of this testing / developement so essential my network is two amigas conected via the router.


Quote:

I think you should work on minimizing the packet rate. The user cannot necessarily generate more than about 60 events per second. If you lump keyboard and mouse events together into a single protocol unit, you might have fewer than 30-40 packets per second that need to be sent. Are you sending packets at a constant rate, or do you only transmit events if you find that the overall event state (keys pressed/depressed, mouse buttons pressed/depressed, mouse position deltas) has changed?

My protocol is adirect analog of the input.device events. I don't do any state handling with WRT keyboard state or mouse button state, rather I tanslate IECLASS_RAWMOUSE IECLASS_RAWKEY and a couple of others directly into a packet, send it to the client and then client builds an input event from it and uses ADDEVENT or WRITEEVENT as appropriate to add it to the client input stream.

iN addiational there are a number of control level commands such as ENTER , tell the client the mouse is enetering it's screen and to expect input events, OUT client tells server it's passing control back to the server etc etc etc

I harvest the events on the server by using a custom commodity handler that watches for the appropriate events and adds coppies of them to a mutex proteced list, signaling the main server task that data is available when it does so.

Under normal operation the queue of events never gets longer than 1 but when doing something harder on the client , like dragging windows arround, a back log can build up, so in this case I agregate all RAWMOUSE events with the same code and qualifier into a single event and send it as one packet. This eliminates lag on the client when dragging windows.

So the upshot of all that is that my event rate is varaible and can peak at 100 events a second or so.

My protocol is synchronous with the client returning at least a RCVD packet (sometimes a more complex response) and the server waiting for this before continuing (or dropping the client if it times out).


I tried a number of experiments to reduce packet rate by moving to timed approach, inserting a Delay(1) in the client respose loop slows down the packet rate to a max of 50 packets a second (each way) stil quite snooth, but didn't appear to affect the incidence of packet drops.

Using timer events in the commodity to signal the main servertask brings it down to 10 packets a second, (too slow and jerky to use) but I stil saw the packet drops.

So I can conclude from the two above experiments that the sheer packet rate is not the cause of the drops.

I realised that I was stil running both client and server at raised priorities afetr intial attempts to deal with window dragging lag, and so returned them down to 0, and still the packets drop :-/

Quote:

It seems to me that your immediate problem is with packet drops, and how TCP handles those. My advice would be to investigate how the packet drops come about.

I'm unsure how I could deteremine where in the setup the packet is dropped.

As far as I'm aware my two beta testers also see these packet drops.

Last edited by broadblues on 06-Sep-2014 at 01:45 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad