Home > Archive > Unix Programming > May 2006 > sending structure through SENDTO()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
sending structure through SENDTO()
|
|
| ataanis@gmail.com 2006-05-26, 7:04 pm |
| I'm currently using the function:
sendto(sockfd, message, strlen(message), 0,&client_addr, addr_size)
to sending a message back to a client, and I was wondering if there was
a way of sending a structure instead, so that I can open it in the
client side?
Thanks
| |
| davids@webmaster.com 2006-05-26, 7:04 pm |
| Follow the specification for the protocol you are implementing. If you
haven't made a protocol specification, you should do that before you
start coding.
The 'sendto' function sends a chunk of bytes. So your protocol
specification should state how information will be exchanged in terms
of bytes.
DS
| |
| ataanis@gmail.com 2006-05-26, 7:04 pm |
| I'm using a udp client/server, this is what I tried to do :
sendto(sockfd, &hostsev, sizeof(hostsev), 0,&client_addr, addr_size)
With hostsev , being a structure where I stored information to be sent
back to the client
and then on the client side , I'm doing the following
msgsize = recvfrom(sockfd,(char*)&answer, sizeof(answer), 0,(struct
sockaddr *)&temp_addr,&addr_length)
with answer being a structure of the same time as hostsev , I
redeclared it in the client part
is this ligitimate?
| |
| Rick Jones 2006-05-26, 7:04 pm |
| ataanis@gmail.com wrote:
> I'm using a udp client/server, this is what I tried to do :
> sendto(sockfd, &hostsev, sizeof(hostsev), 0,&client_addr, addr_size)
> With hostsev , being a structure where I stored information to be sent
> back to the client
> and then on the client side , I'm doing the following
> msgsize = recvfrom(sockfd,(char*)&answer, sizeof(answer), 0,(struct
> sockaddr *)&temp_addr,&addr_length)
> with answer being a structure of the same time as hostsev , I
> redeclared it in the client part
> is this ligitimate?
Only if you know that the components of the structure are the same
size on each system, and that the compiler used to compile each pads
the structure the same way. (A compiler may put "padding" between the
fields of a structure to maintain proper alignment of the components).
rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
| |
| davids@webmaster.com 2006-05-26, 7:04 pm |
| > is this ligitimate?
There is no way to tell from the information you presented. You cannot
compare the server to the client. You must compare both the server and
the client to the specification.
Trust me, you really need to draw up a protocol specification that
explains what *bytes* the client is supposed to send to the server.
Then the client will be legitimate if it sends those bytes and the
server will be legitimate if it properly handles those bytes. You
cannot compare the client to the server directly -- that only leads to
pain.
DS
| |
| Barry Margolin 2006-05-26, 7:04 pm |
| In article <1148678346.853570.152530@j55g2000cwa.googlegroups.com>,
davids@webmaster.com wrote:
>
> There is no way to tell from the information you presented. You cannot
> compare the server to the client. You must compare both the server and
> the client to the specification.
>
> Trust me, you really need to draw up a protocol specification that
> explains what *bytes* the client is supposed to send to the server.
> Then the client will be legitimate if it sends those bytes and the
> server will be legitimate if it properly handles those bytes. You
> cannot compare the client to the server directly -- that only leads to
> pain.
>
> DS
To put a face to this recommendation, the original BSD developers wrote
the "talk" program in essentially the way you're trying to write your
application. The result was that Vax and Sun users could not talk to
each other over the network, because the systems used different byte
orders for int variables. A new "ntalk" protocol had to be developed to
define the proper representation on the network.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Itamar 2006-05-26, 7:04 pm |
| On 2006-05-26 17:19:06 -0400, davids@webmaster.com said:
>
> There is no way to tell from the information you presented. You cannot
> compare the server to the client. You must compare both the server and
> the client to the specification.
>
> Trust me, you really need to draw up a protocol specification that
> explains what *bytes* the client is supposed to send to the server.
> Then the client will be legitimate if it sends those bytes and the
> server will be legitimate if it properly handles those bytes. You
> cannot compare the client to the server directly -- that only leads to
> pain.
>
> DS
And if I may add my two cents: You would assure cross-platform
compatibility is you serialized the data. The price, of course, is
serializing and deserializing, but the benefit is cross platform
transfers and flexibility.
| |
| davids@webmaster.com 2006-05-27, 4:09 am |
| >And if I may add my two cents: You would assure cross-platform
>compatibility is you serialized the data. The price, of course, is
>serializing and deserializing, but the benefit is cross platform
>transfers and flexibility.
Not necessarily. You can do what a lot of vendors do (Sun with Java,
Microsoft with SMB) and design the protocol specification so that it
'just happens' to be identical to the native representation on your
preferred platform.
DS
| |
| Hubble 2006-05-27, 4:09 am |
| >I'm currently using the function:
> sendto(sockfd, message, strlen(message), 0,&client_addr, addr_size)
>to sending a message back to a client, and I was wondering if there was
>
>a way of sending a structure instead, so that I can open it in the
>client side?
>Thanks
A possible way would be to use Sun's XDR protocol (external data
representation). SNMPs BER/ASN.1 (Basic encoding rules/abstract syntax
notation one) is another attempt to achieve portable data
representation on the network. On a theoretical basis, i.e. the OSI
model, this is the representation layer.
Also, you can consider using HTTP or SMTP to hook your data (depending
on your needs).
For a simple protocol, it is worth considering a SMTP like design:
[color=darkred]
<<<GREET <string representation of message>
...[color=darkred]
<<<BYE
The additional processor time is not worth mentioning for most cases
Hubble.
| |
| Itamar 2006-05-27, 7:02 pm |
| On 2006-05-27 01:30:59 -0400, davids@webmaster.com said:
>
> Not necessarily. You can do what a lot of vendors do (Sun with Java,
> Microsoft with SMB) and design the protocol specification so that it
> 'just happens' to be identical to the native representation on your
> preferred platform.
>
> DS
You might be right; BTW: What if you do not control the client's
implementation's platform?
I was referring to times where passing a struct/chunk is not enough.
Instead of using expensive marshalling (vendor-ed) systems, you could
serialize and pass objects without having to worry about their internal
structures (vtables and such).
It would also allow your two systems to still be able to talk to
eachother even if one side was updated and the other not. (You could
achieve the same thing with structs, but it would be 'hazerdous') Using
serialization, the receiving side would only deserialize what was known
to its compiled version, while the sender can incorporate new
fields/methods without breaking old clients.
Itamar
| |
| davids@webmaster.com 2006-05-27, 7:02 pm |
| >BTW: What if you do not control the client's
>implementation's platform?
Generally, server performance is the most important. If you know what
platform the server is likely to be on, you can draw up the
specification so that it "just happens to" call for the format the
server keeps things in anyway. The client has to convert.
I always recommend drafting a specification at the byte level and
making sure the server and client meet that specification. But what the
specification says is up to you, and it would be silly to make it
something that hurt performance where it was important.
You think it's coincidence that Java uses the byte layout that is
fastest on Sparc chips and SMB uses the byte layout that's fastest on
x86? I don't.
DS
|
|
|
|
|