Unix Programming - exchange data a cross sockets

Author

exchange data a cross sockets

Azzedine

2004-11-23, 6:08 pm

Dear all,

could someone please help and tell me if is that possible to send to and
receive data with stuct function through a socket? I'd glad if you 'd send
me example that send() and recv() deal with struct funcfion to transfer
data.

Thanking you in advance for your support

Fletcher Glenn

2004-11-24, 2:59 am

"Azzedine" <a.yahiaoui@bwk.tue.nl> wrote in message
news:cnvtpp$snr$1@news.tue.nl...
> Dear all,
>
> could someone please help and tell me if is that possible to send to and
> receive data with stuct function through a socket? I'd glad if you 'd send
> me example that send() and recv() deal with struct funcfion to transfer
> data.
>
> Thanking you in advance for your support
>
>

It's possible, but it will only work between machines of the same O/S and
architecture.
If you want to exchange this data between machines of different O/S or
architecture, you
must use some form of network representation like XDR.

--

Fletcher Glenn

Azzedine

2004-11-24, 8:12 am

Thank you for you reply. That is very kind of you.

Actually I'm trying to exchange data on the same OSs, but I'm not so
confident in using the primitives of sockets stuff: write()/read() or
send()/recv() because message exchanged between client and server should be
in form of character. In my case I want to exchange data type in form of
double. Is that possible?

Thanking you again in advance for your help

"Fletcher Glenn" <fandxxxmgiiBLOCKED@pacbell.net> wrote in message
news:gWTod.49019$QJ3.21325@newssvr21.news.prodigy.com...
>
> "Azzedine" <a.yahiaoui@bwk.tue.nl> wrote in message
> news:cnvtpp$snr$1@news.tue.nl...
send[vbcol=seagreen]
>
> It's possible, but it will only work between machines of the same O/S and
> architecture.
> If you want to exchange this data between machines of different O/S or
> architecture, you
> must use some form of network representation like XDR.
>
> --
>
>
> Fletcher Glenn
>
>

Nils O. Selåsdal

2004-11-24, 8:12 am

Azzedine wrote:
> Thank you for you reply. That is very kind of you.
>
> Actually I'm trying to exchange data on the same OSs, but I'm not so
> confident in using the primitives of sockets stuff: write()/read() or
> send()/recv() because message exchanged between client and server should be
> in form of character. In my case I want to exchange data type in form of
> double. Is that possible?
Sure.
double d = ...;
write(fd,&d,sizeof(d));

Azzedine

2004-11-24, 8:12 am

"Nils O. Selåsdal" <NOS@Utel.no> wrote in message
news:dzZod.18421$Km6.223337@news4.e.nsc.no...
> Azzedine wrote:
be[vbcol=seagreen]
> Sure.
> double d = ...;
> write(fd,&d,sizeof(d));

Thanks a lot for your reply.
I have tryied this form with send()/recv() but it doesn't work as using msg
in form of character. Is that possible to write data in form struct????
c.a.:
//-------
struct {int a; double b;} data;
// -----
then read from and write to socket.

Thanking you a lot once again for your help.

Jens.Toerring@physik.fu-berlin.de

2004-11-24, 8:12 am

Azzedine <a.yahiaoui@bwk.tue.nl> wrote:

> "Nils O. Selåsdal" <NOS@Utel.no> wrote in message
> news:dzZod.18421$Km6.223337@news4.e.nsc.no...
> be
[vbcol=seagreen]
> Thanks a lot for your reply.
> I have tryied this form with send()/recv() but it doesn't work as using msg
> in form of character. Is that possible to write data in form struct????
> c.a.:
> //-------
> struct {int a; double b;} data;
> // -----
> then read from and write to socket.

Well, unless you tell more clearly how you tried to send and receive
the data it's impossible to tell what and why it went wrong. One
problem could be that both sides may have completely different repre-
sentations of doubles - at least if both machines have different
architectures. On different architectures doubles can even have
different numbers of bits in a double. So, unless you restrict your-
self to machines with the same architecture (and then probably use
the same compiler for the programs on both sides), problems are to
be expected.

Using a structure won't help you there, it only make things more
difficult, since the compiler is allowed to add padding bytes to
structures - and how many that are depends on the architecture,
the compiler and possibly even the version of the compiler.

Usually, it's not a good idea to send data in binary like that
(unless you do local communication over an AF_UNIX socket, of
course). Converting the data to a common representation like
ASCII is one of the ways to deal with these problems.

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Kenny McCormack

2004-11-24, 8:12 am

In article <co1n53$aoq$1@news.tue.nl>, Azzedine <a.yahiaoui@bwk.tue.nl> wrote:
>Thank you for you reply. That is very kind of you.
>
>Actually I'm trying to exchange data on the same OSs, but I'm not so
>confident in using the primitives of sockets stuff: write()/read() or
>send()/recv() because message exchanged between client and server should be
>in form of character. In my case I want to exchange data type in form of
>double. Is that possible?

Obviously, it is possible to send all 256 8 bit characters over a TCPIP
connection (think about the sorts of things that are sent via TCPIP every
day and this becomes obvious). So, the fact that you seem to be having
problems with it is why people are making the assumption that you are
running into some kind of architecture/compiler/etc problem.

Azzedine

2004-11-24, 8:12 am

<Jens.Toerring@physik.fu-berlin.de> wrote in message
news:30jeu3F31cgqaU1@uni-berlin.de...
> Azzedine <a.yahiaoui@bwk.tue.nl> wrote:
>
should[vbcol=seagreen]
of[vbcol=seagreen]
>
msg[vbcol=seagreen]
>
> Well, unless you tell more clearly how you tried to send and receive
> the data it's impossible to tell what and why it went wrong. One
> problem could be that both sides may have completely different repre-
> sentations of doubles - at least if both machines have different
> architectures. On different architectures doubles can even have
> different numbers of bits in a double. So, unless you restrict your-
> self to machines with the same architecture (and then probably use
> the same compiler for the programs on both sides), problems are to
> be expected.
>
> Using a structure won't help you there, it only make things more
> difficult, since the compiler is allowed to add padding bytes to
> structures - and how many that are depends on the architecture,
> the compiler and possibly even the version of the compiler.
>
> Usually, it's not a good idea to send data in binary like that
> (unless you do local communication over an AF_UNIX socket, of
> course). Converting the data to a common representation like
> ASCII is one of the ways to deal with these problems.
>
> Regards, Jens
> --
> \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
> \__________________________ http://www.toerring.de

Thanks a lot for your reply.

I'm trying to exchange data between Matlab and Fortran package over sockets
and I'm using the same compiler.
However, the data that should be exchanged between those two processus are
in floating-point types and they should be the same things in both sides. It
is important as the data exchanged are very accurate in simulation. could
you please help me on hoe to exchange data accuratly a cross sockets???

Thank you once again for your help.

Jens.Toerring@physik.fu-berlin.de

2004-11-24, 8:12 am

Azzedine <a.yahiaoui@bwk.tue.nl> wrote:
> I'm trying to exchange data between Matlab and Fortran package over sockets
> and I'm using the same compiler.
> However, the data that should be exchanged between those two processus are
> in floating-point types and they should be the same things in both sides.

Should be or are they definitely they the same? "Floating point
type" is nothing that has a well-defined meaning in the sense
that a floating point type is e.g. 80 bit everywhere with that
and that binary representation. And does MatLab always use the
native floating point type of the machine it's running on or
perhaps some special type of its own to allow for higher
precision or a larger range (sorry, I am not too familiar
with MatLab)?

What is the code you're using to send and receive the data? Are
both the programs on the same machine or at least on machines
with the same architecture? Have you made sure that MatLab uses
the same binary floating point format as the program your Fortran
compiler creates? Did you do tests like having a MatLab program
send data over the socket, catch the data into a file on the other
side and try to feed them back from the file to MatLab to see if
they still are what you assume they are? Unfortunately, your
problem description

> I have tryied this form with send()/recv() but it doesn't work...

is so vague that it's impossible to figure out just what you could
mean with "it doesn't work". It could be everything, starting with
network problems, incorrect use of send()/recv(), memory corruption,
different binary floating point formats, trouble in the integration
of C with Fortran or MatLab code (do you use C for the transfering
part of your program or what else?) and lots of other things I may
not even be aware of...
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Måns Rullgård

2004-11-24, 8:12 am

Jens.Toerring@physik.fu-berlin.de writes:

> Azzedine <a.yahiaoui@bwk.tue.nl> wrote:
>
> Should be or are they definitely they the same? "Floating point
> type" is nothing that has a well-defined meaning in the sense
> that a floating point type is e.g. 80 bit everywhere with that
> and that binary representation. And does MatLab always use the
> native floating point type of the machine it's running on or
> perhaps some special type of its own to allow for higher
> precision or a larger range (sorry, I am not too familiar
> with MatLab)?

Everywhere I've used Matlab, it used IEEE floating point numbers,
which was also the native format. Are there any widely used
architectures that don't have native IEEE floating point? I don't
consider VAX widely used these days.

--
Måns Rullgård
mru@inprovide.com