write unsigned integer 32 bits to socket

R

rkmr.em

You will need to use struct module to build the 4 byte value and then send
it.

Something like (not tested):

import struct
us32bit = struct.pack("I", value)
s.send(us32bit)

thanks a lot!!!

just to make sure if I want 32 bit or 4 bytes then should I use the
short or integer or long?

this is short'\x00\x03'

this is integer'\x00\x00\x00\x03'

this is long'\x00\x00\x00\x03'
 
R

rkmr.em

Short is 16 bits, Integer is 32 bits, long is 64 bits (as I read and have
found).
thanks a lot!!! re-read it again!!!

from the struct doc!
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and
double are 32-bit and 64-bit IEEE floating point numbers,
respectively.
 
M

Michael Torrie

thanks a lot!!! re-read it again!!!

from the struct doc!
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and
double are 32-bit and 64-bit IEEE floating point numbers,
respectively.

Of course any time you send coherent numbers over the network, I highly
recommend you use what's called network byte order. In C, you'd use the
htonl() call, and then when pulling it off the wire on the other end
you'd use ntohl(). If you don't then you will have problems when the
endianness is different between the hosts. Standard convention (even in
the MS word) is to use big-ending across the network. I'm sure python
has some convention in the struct module for dealing with this.
 
A

Alan Franzoni

Michael Torrie was kind enough to say:
Of course any time you send coherent numbers over the network, I highly
recommend you use what's called network byte order. In C, you'd use the
htonl() call, and then when pulling it off the wire on the other end
you'd use ntohl(). If you don't then you will have problems when the
endianness is different between the hosts. Standard convention (even in
the MS word) is to use big-ending across the network. I'm sure python
has some convention in the struct module for dealing with this.

Not in the struct module; such functions are available in the socket
module, and should be employed indeed.


--
Alan Franzoni <[email protected]>
-
Remove .xyz from my email in order to contact me.
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
 
R

rkmr.em

Please don't pass this misinformation along.

In the struct module document, see the section on the initial character:
Character Byte order Size and alignment
@ native native
= native standard
< little-endian standard
! network (= big-endian) standard
and notes @ is the default.


thanks for clarifying, and just to make sure, i am using '!' format
from the struct package... i had this even in my previous email....
what am doing below is fine right?


this is short'\x00\x03'

this is integer'\x00\x00\x00\x03'

this is long'\x00\x00\x00\x03'
 
A

Alan Franzoni

Scott David Daniels was kind enough to say:
Alan Franzoni wrote:
Please don't pass this misinformation along.

In the struct module document, see the section on the initial character:
Character Byte order Size and alignment
@ native native
= native standard
< little-endian standard
! network (= big-endian) standard

Sure, that's is one way to do it... but I was answering Micheal Torrie, who
said:
htonl() call, and then when pulling it off the wire on the other end
you'd use ntohl(). If you don't then you will have problems when the

htonl() and ntohl() are available in Python in the socket module, so:
1) i was just pointing the OP to the right place where to find such
functions
2) they work just the same way, hence I can't see why the "struct" way
should be the preferred one while the "socket" way should be misinformation
:p

Bye!

--
Alan Franzoni <[email protected]>
-
Remove .xyz from my email in order to contact me.
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top