Socket C

[Thiago Dantas]

One dumb question.

I know that the default network byte organization is Big Endian.
But when i code my applications, only in the serv.sin_port that i
convert from little to big endian.

Should i convert all message that i send to network order ?

char msg[] = "Hello!\n";
send(socketDescriptor, msg, strlen(msg), 0);

best regards
Thiago

 

[Thiago Dantas]

Thanks Richard,

The "Hello" string was only to exemplify.
my question is that im talking with a machine that have big endian as
byte ordering, and my machine ( intel based ) is little endian. So, we
have a restricted protocol to exchange messages.
Should i convert from network order to host order all short (2 bytes)
that i receive ?


best regards
Thiago Dantas

Thiago Dantas said:

One dumb question.

I know that the default network byte organization is Big Endian.
But when i code my applications, only in the serv.sin_port that i
convert from little to big endian.

Should i convert all message that i send to network order ?

char msg[] = "Hello!\n";
send(socketDescriptor, msg, strlen(msg), 0);

Endianness doesn't really apply to chars.

Since you're not sending the terminating null character, how will the
receiver know where the string stops?

Anyway, to answer your question in general, you should *decide* on a
protocol for your messages that is consistent and robust across disparate
systems - assuming, that is, that you have control over the protocol.

If you are using an existing protocol, however, you should observe its
requirements. If the protocol requires "native order", use native order.
If it requires "network order", use that. If it requires "big-endian
order", use that. If it requires text-only transmissions, provide
text-only transmissions. If it requires every message to be preceded by a
blue flamingo playing a saxophone, consider using a different protocol.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

 

[viza]

Hi

The "Hello" string was only to exemplify. my question is that im
talking with a machine that have big endian as
byte ordering, and my machine ( intel based ) is little endian. So, we
have a restricted protocol to exchange messages.
Should i convert from network order to host order all short (2 bytes)
that i receive ?

This is nothing to do with C so I have marked Off-Topic in the subject
line.

TCP/IP sends data in 8-bit bytes. As far as that protocol suite is
concerned these are atomic and and do not have a big end and small end.

If you choose to use these 8-bit bytes to send some larger sized object
then it is up to you to decide what order to send the parts in.

You are correct that it is conventional to send the higher-order bytes
("big end") first.

As Richard said, if you are making up your own protocol, do what you like
and do it consistently. If you are using a higher level protocol that
someone else has created, then read their documentation as to how it
should be done. Most protocols (http, smtp, pop etc.) are text oriented
and transmit in single bytes.

HTH
viza

PS: you wrote your response above the text of Richards message. It
should have been below it, so that people can read top to bottom.

 

[Keith Thompson]

Thiago Dantas said: [...]

char msg[] = "Hello!\n";
send(socketDescriptor, msg, strlen(msg), 0);

Endianness doesn't really apply to chars.

Since you're not sending the terminating null character, how will the
receiver know where the string stops?

[...]

Perhaps by seeing the '\n'.

You wouldn't write the trailing '\0' to a text file; it's plausible
that you wouldn't want to write it to a socket either. But of course
it depends on the protocol.

 

[Richard Tobin]

Anyway, to answer your question in general, you should *decide* on a
protocol for your messages that is consistent and robust across disparate
systems - assuming, that is, that you have control over the protocol.

But if you are in this situation, and have no compelling reason to do
otherwise, then you should choose big-endian, since that is what most
other internet protocols use. "Network byte order" means big endian.

See for example

http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt

-- Richard

 

[CBFalconer]

The "Hello" string was only to exemplify. my question is that im
talking with a machine that have big endian as byte ordering, and
my machine ( intel based ) is little endian. So, we have a
restricted protocol to exchange messages. Should i convert from
network order to host order all short (2 bytes) that i receive ?

Big/little endian doesn't affect chars (bytes). Any multi-byte
object (apart from strings and arrays of char) transmitted over the
network will be in network byte order. This should be big endian.
Most systems have routines to convert to and from network byte
order, and these are customized to your native system. Use them
and the problems are handled. If you don't have them write them.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

 

[Keith Thompson]

Big/little endian doesn't affect chars (bytes). Any multi-byte
object (apart from strings and arrays of char) transmitted over the
network will be in network byte order. This should be big endian.

Did you mean "should be" rather than "will be"?

Objects transmitted over the network will be in network byte order
only if you ensure that they're transmitted that way. It's perfectly
feasible (though often unwise) to transmit data in native byte order;
it can even make sense to do so if you happen to know that the systems
on both ends are consistent.

[...]

 

[Thiago Dantas]

Thiago Dantas wrote:

Big/little endian doesn't affect chars (bytes).  Any multi-byte
object (apart from strings and arrays of char) transmitted over the
network will be in network byte order.  This should be big endian.

Did you mean "should be" rather than "will be"?

Objects transmitted over the network will be in network byte order
only if you ensure that they're transmitted that way.  It's perfectly
feasible (though often unwise) to transmit data in native byte order;
it can even make sense to do so if you happen to know that the systems
on both ends are consistent.

[...]

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Thanks Thompson,

yeah, doesn't make sense char in big or little endian. But if i trying
to send a unicode char ( 2 bytes ) between java ( JVM is Big endian )
and a C ( intel x86 - Little endian ). Should i convert to take the
correct character, all right ?

 

[Richard Tobin]

yeah, doesn't make sense char in big or little endian. But if i trying
to send a unicode char ( 2 bytes ) between java ( JVM is Big endian )
and a C ( intel x86 - Little endian ). Should i convert to take the
correct character, all right ?

UTF-16 allows for a "byte order mark" (BOM) at the beginning of a
stream. This is a character (hex FEFF) whose byte-reversed value is
an illegal character, allowing the receiver to determine the
byte-order of the stream.

-- Richard

 

[Keith Thompson]

yeah, doesn't make sense char in big or little endian. But if i trying
to send a unicode char ( 2 bytes ) between java ( JVM is Big endian )
and a C ( intel x86 - Little endian ). Should i convert to take the
correct character, all right ?

As several people have said several times, it depends on the protocol.

 

[Thiago Dantas]

UTF-16 allows for a "byte order mark" (BOM) at the beginning of a
stream.  This is a character (hex FEFF) whose byte-reversed value is
an illegal character, allowing the receiver to determine the
byte-order of the stream.

-- Richard

Thanks Tobin

Now is working ! Really appreciate the BOM.
I never thought of pass over network the BOM at the first 2 bytes to
the another peer.
thank u very much. Now can i correct the third party protocol.

thanks

 

[Tim Rentsch]

Big/little endian doesn't affect chars (bytes). Any multi-byte
object (apart from strings and arrays of char) transmitted over the
network will be in network byte order. This should be big endian.

Did you mean "should be" rather than "will be"?

Objects transmitted over the network will be in network byte order
only if you ensure that they're transmitted that way. [...]

I expect most people understood what you meant, but that isn't
what was said.

Objects transmitted over a network will be in network byte order
IF the code ensures that they're transmitted that way.

Objects transmitted over a network will ALSO be in network byte
order if a program doesn't ensure any particular ordering but
happens to be running on a machine that matches the assumptions
about ordering made by the code.

Objects transmitted over a network /are guaranteed to be/ in
network byte order only if the code ensures correct ordering.