## 3.1 Binary Data 

It is perfectly possible to send binary data over a socket. The major problem is that not all machines use the same formats for binary data. For example, a Motorola chip will represent a 16 bit integer with the value 1 as the two hex bytes 00 01. Intel and DEC, however, are byte-reversed - that same 1 is 01 00. Socket libraries have calls for converting 16 and 32 bit integers - ntohl, htonl, ntohs, htons where “n” means network and “h” means host , “s” means short and “l” means long . Where network order is host order, these do nothing, but where the machine is byte-reversed, these swap the bytes around appropriately. 

In these days of 32 bit machines, the ascii representation of binary data is frequently smaller than the binary repre- sentation. That’s because a surprising amount of the time, all those longs have the value 0, or maybe 1. The string “0” would be two bytes, while binary is four. Of course, this doesn’t fit well with fixed-length messages. Decisions, decisions. 

## 4 Disconnecting 

Strictly speaking, you’re supposed to use $_{shutdown}$on a socket before you $_{close}$it. The $_{shutdown}$is an advisory to the socket at the other end. Depending on the argument you pass it, it can mean “I’m not going to send anymore, but I’ll still listen”, or “I’m not listening, good riddance!”. Most socket libraries, however, are so used to programmers neglecting to use this piece of etiquette that normally a $_{close}$is the same as shutdown(); close() . So in most situations, an explicit$_{shutdown}$is not needed. 

One way to use$_{shutdown}$ effectively is in an HTTP-like exchange. The client sends a request and then does a shutdown(1) . This tells the server “This client is done sending, but can still receive.” The server can detect “EOF” by a receive of 0 bytes. It can assume it has the complete request. The server sends a reply. If the$_{send}$ completes successfully then, indeed, the client was still receiving. 

Python takes the automatic shutdown a step further, and says that when a socket is garbage collected, it will auto- matically do a$_{close}$if it’s needed. But relying on this is a very bad habit. If your socket just disappears without doing a$_{close}$, the socket at the other end may hang indefinitely, thinking you’re just being slow. Please$_{close}$ your sockets when you’re done. 

## 4.1 When Sockets Die 

Probably the worst thing about using blocking sockets is what happens when the other side comes down hard (without doing a$_{close}$). Your socket is likely to hang. TCP is a reliable protocol, and it will wait a long, long time before giving up on a connection. If you’re using threads, the entire thread is essentially dead. There’s not much you can do about it. As long as you aren’t doing something dumb, like holding a lock while doing a blocking read, the thread isn’t really consuming much in the way of resources. Do not try to kill the thread - part of the reason that threads are more efficient than processes is that they avoid the overhead associated with the automatic recycling of resources. In other words, if you do manage to kill the thread, your whole process is likely to be screwed up. 

## 5 Non-blocking Sockets 

If you’ve understood the preceding, you already know most of what you need to know about the mechanics of using sockets. You’ll still use the same calls, in much the same ways. It’s just that, if you do it right, your app will be almost inside-out. 

In Python, you use$_{socket.setblocking(False)}$ to make it non-blocking. In C, it’s more complex, (for one thing, you’ll need to choose between the BSD flavor$_{O_NONBLOCK}$ and the almost indistinguishable POSIX flavor O_NDELAY , which is completely different from$_{TCP_NODELAY}$ ), but it’s the exact same idea. You do this after creating the socket, but before using it. (Actually, if you’re nuts, you can switch back and forth.) 

The major mechanical difference is that $_{send}$, recv , $_{connect}$and $_{accept}$can return without having done anything. You have (of course) a number of choices. You can check return code and error codes and generally drive 

