Re: [SPAM] Re: Incompatible data size using 32 bits SocketAppender and 64 bits S ocketNode

I'm surprised that it doesn't use the "ntohl/htonl" functions... we use those extensively for any type of socket/UDP comms, as that gives the flexibility of cross-platform (mainly diff byte ordering/word size) support.

Renny Koshy
President & CEO

--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com

Curt Arnold <carnold@xxxxxxxxxx> 12/22/2004 09:22 AM Please respond to "Log4CXX User"

To:        Log4CXX User <log4cxx-user@xxxxxxxxxxxxxxxxxx>         cc:                 Subject:        [SPAM] Re: Incompatible data size using 32 bits SocketAppender and 64 bits S ocketNode

I added your comment to the existing LOGCXX-7 bug on the socket format 
being incompatible with Chainsaw 
(http://nagoya.apache.org/jira/browse/LOGCXX-7).


On Dec 22, 2004, at 6:04 AM, Sluis, Minto van der wrote:

> Hi,
>
> After a little bit of struggling we succeeded in building
> 0.9.7 on the tru64 using the compaq cxx compiler. However,
> we now run into a runtime problem.
>
> Using the DelayedLoop example and the simple socket server
> on the same platform works fine. However, if we run the
> DelayedLoop example on windows and the simple socket server
> on tru64 it does not work. DeleyedLoop does succeed in
> establishing a connection with the socket server, however
> no messages arrive (also no error reports on either
> side). We suspect something like an 32 bits integer is written
> and a 64 bits integer is read. Could this be the case? If
> so, will this still be the case in the next release?
>
> After some poking around (in CVS head) I discovered that
> the SocketOutputStream class uses plain int, long and
> unsigned int types for writing data to the socket.
> Shouldn't this be some kind of platform safe types?
>
> How is this best fixed?
>
> regards,
>
> Minto van der Sluis
>