Same way as a string:
- by encoding it,
- transfering it via the IPC mechanism,
- then decoding it.
Now many high-level languages provide nice seamless abstractions that let you read and write objects to and from pipes. They establish a generic (or specific) object protocol for you that takes care of encoding/decoding. This liberates you to focus on the specific objects you wish to send/receive without bothering about how they are sent/received.
Most applications go through this path of using these high-level abstractions because generally they are proven, well-maintained, and reduce the burden of details you have to work with. This would include things like SOAP, HTTP, SMTP, etc... If you can use these.
Sometimes though either because you wish to learn, or because nothing suitable exists you need to write that adapter library yourself.
So take a moment and consider what the pipe is really doing.
The pipe at its core is taking a sequence of units and transferring them to the other end, with some guarantee (or lack) about how/when/what is delivered. The units could be bits, or maybe groups of 8 bits. Other groupings are possible and the pipe might even use trinary. For the most part 8bits tends to be standard, and a sequence of these is just an array.
So now the question becomes how do you map some object onto an array of bytes?
Well for a string this can be very simple. Because a string is an array of characters, and a character is stored by one or more sequential code-points. If those code-points are bytes like with UTF-8 or ASCII then a string is just an array of bytes.
Now if the code-points are larger than a byte, how can this happen?
Notice that this code point is an integer of some size. Common sizes might be 16bits, 24bits, 32bits, 64bits, or 128bits. These are all some multiple of 8, thus we can "encode" a number by splitting its bits up into bytes, and then sending those bytes in some order. The receiver only needs to move those bits back into the correct positions in the integer on the other end.
So in what order should those bytes be sent?
This is where you need to know how the computer stores integers. This is important because the hexadecimal unsigned 16bit number
0x8000 on a
little endian is: 128, but on a
big-endian is: 32768. So most protocols define something called network order. This is the ordering of the bytes/bits in an integer on the wire and allows computers that store integers differently to still send and receive integers with each other.
Usually Big-Endian is used as the network order. Mostly this is historical, but as it is a defacto standard, it helps to lower confusion, and more importantly the ordering is intuitive. In BigEndian the byte containing the most significant part of the number is sent first, and so on till the byte with the lowest significance is sent last. For example if the network sent 3 decimal digits and we had a 3 unit number:
+++ +++ +++
12 730 234
Then, a big endian network ordering would send an array like:
[ 12, 730, 234 ]
Conversely Little endian on the network would look like:
[ 234, 730, 12 ]
Protocols and Bit Manipulation
You'll need to research communication protocols. Largely because you need to orchestrate the communication between the server and the client. They need to agree on what is being sent/received next so that they don't get confused.
You will also need to look a Bit manipulation if you wish to write your own protocol library. Otherwise you will have a very inefficient implementation (which is fine for learning, not so fine for production).