Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS

[Olivier Baur]

Le samedi, 31 mai 2003, à 11:23 Europe/Paris, Joern Thyssen a écrit :

> The remote pu was a bit more tricky. Perhaps there are some subttle
> differences between Mac and unix?! I'm no socket-wizard, so I just did
> some trial-n-error :-)
>
> For the slave to work:
>
> First, I removed the SO_RCVTIME0 and SNDTIME0 options on the sockets.
> According to my man page:
>
>        SO_RCVTIMEO and SO_SNDTIMEO
>               Specify the sending  or  receiving  timeouts  until
>               reporting  an  error.  They are fixed to a protocol
>               specific setting in Linux and  cannot  be  read  or
>               written.  Their functionality can be emulated using
>               alarm(2) or setitimer(2).
>
> Apperently they have to be protected by some #if LINUX directive.

Okay. So I'll set a timer if LINUX is set instead of setting a socket 
timeout. It should do the job.


> For the master I changed:
>
> remoteAddress.sin_addr.s_addr = 
> htonl(ppu->info.remote.inAddress.s_addr);
>
> to
>
> remoteAddress.sin_addr.s_addr = ppu->info.remote.inAddress.s_addr;
>
> THat is, removed the call to htonl. inAddress is already calculated
> using inet_aton so it must be in network byte order already. So no need
> to call htonl.
>
> This seems to work.

Ooops. Macs are big-endian (ie, "network byte order"), so I didn't 
notice this one. Thanks for pointing out.


BTW, talking about byte ordering, I'll have to do some work to have the 
data exchanged by remote processing units (rpu_message) be in a 
platform independent format (for now, rpu's basically exchange structs, 
which will work only between platforms which have the same byte 
ordering and the same struct field alignment)


-- Olivier