Re: [Aria-users] Using ArClientBase and ArServerBase with UDP protocol

[Matt LaFary <XXXXXXXX>]

ArNetworking by default uses both TCP and UDP.  It uses TCP for all the 
really important things (requests and connection info) and uses UDP for 
most of the rest of the data unless it can't connect the udp (normally 
because of a firewall) or you tell it to explicity use TCP only.  The 
only normal data I can think of that gets sent over tcp from the server 
is the config (since its really important and only sent once in a 
while).  There isn't that much data that goes from the client to the 
server.

Switching the client to server connections may work okay if you're just 
trying to move the requests over to UDP, the connection stuff I'd advise 
against (go ahead if you want to, but expect problems that I can't help 
you with).  I can see a good case for making 'requestOnce' so that 
ArClientBase could do the request once over UDP, and I could put this 
into the next version if it'd make anyone's life easier (let me know if 
it would).  I can see it making sense for requestOnce since this is how 
large amounts of data would normally be sent to the server.  request I 
don't really see as viable over UDP since its a very small amount of 
data and only sent when the interval changes.

Anyways, Aria and ArNetworking come with their source, so you should be 
able to just rebuild Aria.dll and ArNetworking.dll and then that should 
solve your linking allocation spaces issue.  You might have to change 
some of the settings on your program or on the Aria/ArNetworking 
projects so that they compile things the same way but that shouldn't a 
big deal.  Aria.sln in the top level directory has the Aria and 
ArNetworking projects in it along with the two example programs.

Your problem may also be that for your overriding you may need to make 
some functions in ArClientBase virtual so that you can override them 
right.  Just put a virtual in front of them in the header before you 
recompile and that (and/or the above paragraph) should take care of it. 
  If you have to do this for any of them let me know and I'll make them 
virtual for the next version.

I've already implemented a function that'll find the command name from a 
number (it'll be in the next release).  I've cut and pasted it below my 
signature, you can just insert that into the ArClientBase you have and 
with the next version it should already be there with those same 
arguments and name.  Note that I've redone how the locking works to make 
ArClientBase more threadsafe but this function here has no locks in it 
(since I took them out since they don't exist in your version).

If you let me know more about the root problem you're trying to solve by 
moving more over to UDP I might be able to offer some better advice 
and/or set things up for the next release to address them (I might be 
able to send you just a new ArClientBase with those features in it).

Matt LaFary
MobileRobots Inc
ActivMedia Robotics


/**
    @param name the name of the data to find the command of

    @return 0 if there is no command of that name, the command number
    otherwise
**/
AREXPORT unsigned int ArClientBase::findCommandFromName(
           const char *name)
{
   std::map<std::string, unsigned int>::iterator it;
   unsigned int ret;

   if ((it = myNameIntMap.find(name)) == myNameIntMap.end())
   {
     ArLog::log(ArLog::Normal,
        "Finding command for \"%s\" but no data with that name exists",
	       name);
     return 0;
   }
   ret = (*it).second;
   return ret;
}

Marko Budisic wrote:
> Hello,
> 
> I am trying to use ArClientBase and ArServerBase classes to communicate 
> between a robot and a workstation. I would like to retain the structure 
> of client/server, which include announciong commands that are recognized 
> by the server, callback function addition etc. However, I would prefer 
> to use UDP protocol instead of TCP protocol. I am using VS2005 on WinXP.
> 
> If I understood the API correctly, sending data from the client side 
> should be done by request and requestOnce functions. Both functions use 
> TCP socket for sending data. I have tried inheriting from ArClientBase 
> class and overriding request functions to use UDP for sending data. 
> Unfortunately, at run-time, my program fails as it cannot interpret 
> myNameIntMap, which holds information about commands registered on 
> server side, correctly. In the debug mode, the object itself appears to 
> be corrupted, although precompiled functions (as dataExists and getName) 
> work properly.
> 
> I have searched the Internet for the solution with little success. The 
> only piece of information that I managed to find is that the problem 
> most likely arises due to different allocation spaces used by DLL 
> library and my executable.
> 
> Is there another (maybe more obvious way) of solving this problem? The 
> only thing I need to achieve is to get command code from the name 
> (similar to dataExists function, just to get the code as the return 
> value). Everything else would be achieved by inheritance and overriding. 
> If there is another approach altogether, I am interested to try it.
> 
> Thank you for your help
> Marko Budisic
>