Foundations of Python Network Programming 978-1-4302-3004-5

Recommendations

Info

CHAPTER 4 ■ SOCKET NAMES AND DNS For example, consider the domain name www.python.org. If your web browser needs to know this address, then the browser runs a call like getaddrinfo() to ask the operating system to resolve that name. Your system will know either that it is running a nameserver of its own, or that the network to which it is attached provides name service. Nameserver information these days is typically learned automatically through DHCP, whether in corporate offices, in schools, on wireless networks, or on home cable and DSL connections. In other cases, the DNS server IP addresses will have been configured by hand when a system administrator set up your machine. Either way, the DNS servers must typically be specified as IP addresses, since you obviously cannot use DNS itself to find them! Sometimes people are unhappy with their ISP's DNS behavior or performance and choose to configure a third-party DNS server of their own choosing, like the servers at 8.8.8.8 and 8.8.4.4 run by Google. And in some rarer cases, the local DNS domain nameservers are known through some other set of names in use by the computer, like the WINS Windows naming service. But one way or another, a DNS server must be identified for name resolution to continue. Checking DNS for the hostname is not actually the first thing that an operating system usually does when you make a call like getaddrinfo()—in fact, because making a DNS query can be time-consuming, it is often the very last choice! Depending on the hosts entry in your /etc/nsswitch.conf if you are on a POSIX box, or else depending on your Windows control panel settings, there might be one or several other places that the operating system looks first before turning to DNS. On my Ubuntu laptop, for example, the /etc/hosts file is checked first on every single hostname lookup; then a specialized protocol called multicast DNS is used, if possible; and only if that fails or is unavailable is full-blown DNS cranked up to answer the hostname query. To continue our example, imagine that the name www.python.org has not, in fact, been recently enough queried to be in any local cache on the machine where you are running your web browser. In that case, the computer will look up the local DNS server and, typically, send it a DNS request packet over UDP. Now the question is in the hands of a real DNS server! For the rest of this discussion, we will call it “your DNS server,” in the sense of “the DNS server that is doing work for you”; but, of course, the server itself probably belongs to someone else, like your employer or your ISP or Google! The first act of your DNS server will be to check its own cache of recently queried domain names to see if www.python.org has already been checked by some other machine served by the DNS server in the last few minutes or hours. If an entry is present and has not yet expired—and the owner of each domain name gets to choose its expiration timeout, because some organizations like to change IP addresses quickly if they need to, while others are happy to have old IP addresses linger for hours or days in the world's DNS caches—then it can be returned immediately. But let us imagine that it is morning and that you are the first person in your office or in the coffee shop to try talking to www.python.org today, and so the DNS server has to go find the hostname from scratch. Your DNS server will now begin a recursive process of asking about www.python.org at the very top of the world's DNS server hierarchy: the “root-level” nameservers that know all of the top-level domains (TLDs) like .com, .org, .net, and all of the country domains, and know the groups of servers that are responsible for each. Nameserver software generally comes with the IP addresses of these top-level servers built in, to solve the bootstrapping problem of how you find any domain nameservers before you are actually connected to the domain name system! With this first UDP round-trip, your DNS server will learn (if it did not know already from another recent query) which servers keep the full index of .org domain. Now a second DNS request will be made, this time to one of the .org servers, asking who on earth runs the python.org domain. You can find out what those top-level servers know about a domain by running the whois command-line program on a POSIX system, or use one of the many “whois” web pages online: $ whois python.org Domain Name:PYTHON.ORG Created On:27-Mar-1995 05:00:00 UTC Last Updated On:07-Sep-2006 20:50:54 UTC 64
CHAPTER 4 ■ SOCKET NAMES AND DNS Expiration Date:28-Mar-2016 05:00:00 UTC ... Registrant Name:Python Software Foundation ... Name Server:NS2.XS4ALL.NL Name Server:NS.XS4ALL.NL And that provides our answer! Wherever you are in the world, your DNS request for any hostname within python.org must be passed on to one of the two DNS servers named in that entry. Of course, when your DNS server makes this request to a top-level domain nameserver, it does not really get back only two names like those just given; instead, it is also given their IP addresses so that it can contact them directly without incurring another round of DNS lookup. Your DNS server is now finished talking to both the root-level DNS server and the top-level .org DNS server, and can communicate directly with NS2.XS4ALL.NL or NS.XS4ALL.NL to ask about the python.org domain—and, in fact, it will usually try one of them and then fall back to trying the other if the first one is unavailable. This increases the chances of you getting an answer, but, of course, it can increase the amount of time that you sit staring at your web browser before the page can actually be displayed! Depending on how python.org has its nameservers configured, the DNS server might require just one more query to get its answer, or it might take several if the organization is a large one with many departments and sub-departments that all run their own DNS servers to which requests need to be delegated. In this case, the www.python.org query can be answered directly by either of the two servers just named, and your DNS server can now return a UDP packet to your browser telling it which IP addresses belong to that hostname. Note that this process required four separate network round-trips. Your machine made a request and got a response from your own DNS server, and in order to answer that request, your DNS server had to make a recursive query that consisted of three different round-trips to other servers. No wonder your browser sits there spinning when you enter a domain name for the first time! Why Not to Use DNS The foregoing explanation of a typical DNS query has, I hope, made clear that your operating system is doing a lot for you when you need a hostname looked up. For this reason, I am going to recommend that, unless you absolutely need to speak DNS for some quite particular reason, you always rely on getaddrinfo() or some other system-supported mechanism for resolving hostnames. Consider the benefits: • The DNS is often not the only way that a system gets name information. If your application runs off and tries to use DNS on its own as its first choice for resolving a domain name, then users will notice that some computer names that work everywhere else on your system—in their browser, in file share names, and so forth—suddenly do not work when they use your application, because you are not deferring to mechanisms like WINS or /etc/hosts like the operating system itself does. • The local machine probably has a cache of recently queried domain names that might already know about the host whose IP address you need. If you try speaking DNS yourself to answer your query, you will be duplicating work that has already been done. 65
Page 2 and 3:
Foundations of Python Network Progr
Page 4 and 5:
To the Python community for creatin
Page 6 and 7:
Contents ■Contents at a Glance ..
Page 8 and 9:
■ CONTENTS Asking getaddrinfo() W
Page 10 and 11:
■ CONTENTS Using Message Queues f
Page 12 and 13:
■ CONTENTS Parsing Dates ........
Page 14 and 15:
■ CONTENTS Telnet ...............
Page 16 and 17:
About the Authors ■ Brandon Craig
Page 18 and 19:
Acknowledgements This book owes its
Page 20 and 21:
■ INTRODUCTION If you do know som
Page 22 and 23:
C H A P T E R 1 ■ ■ ■ Introdu
Page 24 and 25:
CHAPTER 1 ■ INTRODUCTION TO CLIEN
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Page 34 and 35: CHAPTER 1 ■ INTRODUCTION TO CLIEN
Page 36 and 37: C H A P T E R 2 ■ ■ ■ UDP The
Page 38 and 39: CHAPTER 2 ■ UDP server with SSH.
Page 40 and 41: CHAPTER 2 ■ UDP them anywhere in
Page 42 and 43: CHAPTER 2 ■ UDP command-line argu
Page 44 and 45: CHAPTER 2 ■ UDP » » » » raise
Page 46 and 47: CHAPTER 2 ■ UDP world itself give
Page 48 and 49: CHAPTER 2 ■ UDP socket that is no
Page 50 and 51: CHAPTER 2 ■ UDP So binding to an
Page 52 and 53: CHAPTER 2 ■ UDP s.connect((hostna
Page 54 and 55: CHAPTER 2 ■ UDP else: » print >>
Page 56 and 57: C H A P T E R 3 ■ ■ ■ TCP The
Page 58 and 59: CHAPTER 3 ■ TCP situation), and t
Page 60 and 61: CHAPTER 3 ■ TCP » reply = recv_a
Page 62 and 63: CHAPTER 3 ■ TCP guess when the in
Page 64 and 65: CHAPTER 3 ■ TCP the system has no
Page 66 and 67: CHAPTER 3 ■ TCP » » » print '\
Page 68 and 69: CHAPTER 3 ■ TCP $ python tcp_dead
Page 70 and 71: CHAPTER 3 ■ TCP Using TCP Streams
Page 72 and 73: CHAPTER 4 ■ SOCKET NAMES AND DNS
Page 92 and 93: CHAPTER 5 ■ NETWORK DATA AND NETW
Page 106 and 107: C H A P T E R 6 ■ ■ ■ TLS and
Page 108 and 109: CHAPTER 6 ■ TLS AND SSL systems a
Page 110 and 111: CHAPTER 6 ■ TLS AND SSL • He wi
Page 112 and 113: CHAPTER 6 ■ TLS AND SSL discussio
Page 114 and 115: CHAPTER 6 ■ TLS AND SSL • The s
Page 116 and 117: CHAPTER 6 ■ TLS AND SSL The Links
Page 118 and 119: C H A P T E R 7 ■ ■ ■ Server
Page 120 and 121: CHAPTER 7 ■ SERVER ARCHITECTURE P
Page 122 and 123: CHAPTER 7 ■ SERVER ARCHITECTURE
Page 124 and 125: CHAPTER 7 ■ SERVER ARCHITECTURE N
Page 126 and 127: CHAPTER 7 ■ SERVER ARCHITECTURE L
Page 128 and 129: CHAPTER 7 ■ SERVER ARCHITECTURE F
Page 130 and 131: CHAPTER 7 ■ SERVER ARCHITECTURE
Page 132 and 133: CHAPTER 7 ■ SERVER ARCHITECTURE p
Page 134 and 135:
CHAPTER 7 ■ SERVER ARCHITECTURE N
Page 136 and 137:
CHAPTER 7 ■ SERVER ARCHITECTURE L
Page 138 and 139:
CHAPTER 7 ■ SERVER ARCHITECTURE
Page 140 and 141:
CHAPTER 7 ■ SERVER ARCHITECTURE s
Page 142 and 143:
CHAPTER 7 ■ SERVER ARCHITECTURE c
Page 144 and 145:
C H A P T E R 8 ■ ■ ■ Caches,
Page 146 and 147:
CHAPTER 8 ■ CACHES, MESSAGE QUEUE
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
C H A P T E R 9 ■ ■ ■ HTTP Th
Page 158 and 159:
CHAPTER 9 ■ HTTP Here, the URL sp
Page 160 and 161:
CHAPTER 9 ■ HTTP Relative URLs Ve
Page 162 and 163:
CHAPTER 9 ■ HTTP From now on, I a
Page 164 and 165:
CHAPTER 9 ■ HTTP • 303 See Othe
Page 166 and 167:
CHAPTER 9 ■ HTTP You cannot tell
Page 168 and 169:
CHAPTER 9 ■ HTTP Instead of stuff
Page 170 and 171:
CHAPTER 9 ■ HTTP POST And APIs Al
Page 172 and 173:
CHAPTER 9 ■ HTTP Content Type Neg
Page 174 and 175:
CHAPTER 9 ■ HTTP HTTP Caching Man
Page 176 and 177:
CHAPTER 9 ■ HTTP If the connectio
Page 178 and 179:
CHAPTER 9 ■ HTTP >>> import cooki
Page 180 and 181:
CHAPTER 9 ■ HTTP So the technique
Page 182 and 183:
C H A P T E R 10 ■ ■ ■ Screen
Page 184 and 185:
CHAPTER 10 ■ SCREEN SCRAPING Figu
Page 186 and 187:
CHAPTER 10 ■ SCREEN SCRAPING cont
Page 188 and 189:
CHAPTER 10 ■ SCREEN SCRAPING Thir
Page 190 and 191:
CHAPTER 10 ■ SCREEN SCRAPING Ther
Page 192 and 193:
CHAPTER 10 ■ SCREEN SCRAPING Beau
Page 194 and 195:
CHAPTER 10 ■ SCREEN SCRAPING If y
Page 196 and 197:
CHAPTER 10 ■ SCREEN SCRAPING Cond
Page 198 and 199:
C H A P T E R 11 ■ ■ ■ Web Ap
Page 200 and 201:
CHAPTER 11 ■ WEB APPLICATIONS Thi
Page 202 and 203:
CHAPTER 11 ■ WEB APPLICATIONS But
Page 204 and 205:
CHAPTER 11 ■ WEB APPLICATIONS the
Page 206 and 207:
CHAPTER 11 ■ WEB APPLICATIONS •
Page 208 and 209:
CHAPTER 11 ■ WEB APPLICATIONS hig
Page 210 and 211:
CHAPTER 11 ■ WEB APPLICATIONS The
Page 212 and 213:
CHAPTER 11 ■ WEB APPLICATIONS the
Page 214 and 215:
CHAPTER 11 ■ WEB APPLICATIONS The
Page 216 and 217:
C H A P T E R 12 ■ ■ ■ E-mail
Page 218 and 219:
CHAPTER 12 ■ E-MAIL COMPOSITION A
Page 220 and 221:
Page 222 and 223:
Page 224 and 225:
Page 226 and 227:
Page 228 and 229:
Page 230 and 231:
Page 232 and 233:
Page 234 and 235:
Page 236 and 237:
C H A P T E R 13 ■ ■ ■ SMTP A
Page 238 and 239:
CHAPTER 13 ■ SMTP anyway. Outgoin
Page 240 and 241:
CHAPTER 13 ■ SMTP How SMTP Is Use
Page 242 and 243:
CHAPTER 13 ■ SMTP This mechanism
Page 244 and 245:
CHAPTER 13 ■ SMTP s = smtplib.SMT
Page 246 and 247:
CHAPTER 13 ■ SMTP ETRN STARTTLS X
Page 248 and 249:
CHAPTER 13 ■ SMTP » s = smtplib.
Page 250 and 251:
CHAPTER 13 ■ SMTP exchange mail o
Page 252 and 253:
CHAPTER 13 ■ SMTP username = sys.
Page 254 and 255:
C H A P T E R 14 ■ ■ ■ POP PO
Page 256 and 257:
CHAPTER 14 ■ POP ■ Caution! Whi
Page 258 and 259:
CHAPTER 14 ■ POP finally: » p.qu
Page 260 and 261:
CHAPTER 14 ■ POP Subject: Backup
Page 262 and 263:
CHAPTER 15 ■ IMAP THE IMAP PROTOC
Page 264 and 265:
CHAPTER 15 ■ IMAP '(\\HasNoChildr
Page 266 and 267:
CHAPTER 15 ■ IMAP Examining Folde
Page 268 and 269:
CHAPTER 15 ■ IMAP Listing 15-5. D
Page 270 and 271:
CHAPTER 15 ■ IMAP key that IMAP h
Page 272 and 273:
CHAPTER 15 ■ IMAP » » print def
Page 274 and 275:
CHAPTER 15 ■ IMAP » From: Brando
Page 276 and 277:
CHAPTER 15 ■ IMAP • \Flagged: T
Page 278 and 279:
CHAPTER 15 ■ IMAP An IMAP message
Page 280 and 281:
CHAPTER 15 ■ IMAP display or summ
Page 282 and 283:
CHAPTER 16 ■ TELNET AND SSH cloud
Page 284 and 285:
CHAPTER 16 ■ TELNET AND SSH Unix
Page 286 and 287:
CHAPTER 16 ■ TELNET AND SSH Do yo
Page 288 and 289:
CHAPTER 16 ■ TELNET AND SSH As we
Page 290 and 291:
CHAPTER 16 ■ TELNET AND SSH tabif
Page 292 and 293:
CHAPTER 16 ■ TELNET AND SSH repla
Page 294 and 295:
CHAPTER 16 ■ TELNET AND SSH Listi
Page 296 and 297:
CHAPTER 16 ■ TELNET AND SSH def p
Page 298 and 299:
CHAPTER 16 ■ TELNET AND SSH We wi
Page 300 and 301:
CHAPTER 16 ■ TELNET AND SSH • p
Page 302 and 303:
CHAPTER 16 ■ TELNET AND SSH You w
Page 304 and 305:
CHAPTER 16 ■ TELNET AND SSH » »
Page 306 and 307:
CHAPTER 16 ■ TELNET AND SSH Listi
Page 308 and 309:
CHAPTER 16 ■ TELNET AND SSH Summa
Page 310 and 311:
CHAPTER 17 ■ FTP The biggest prob
Page 312 and 313:
CHAPTER 17 ■ FTP f.login() print
Page 314 and 315:
CHAPTER 17 ■ FTP if os.path.exist
Page 316 and 317:
CHAPTER 17 ■ FTP f = FTP(host) f.
Page 318 and 319:
CHAPTER 17 ■ FTP Windows servers
Page 320 and 321:
CHAPTER 17 ■ FTP » try: » » f.
Page 322 and 323:
C H A P T E R 18 ■ ■ ■ RPC Re
Page 324 and 325:
CHAPTER 18 ■ RPC sort of proxy ex
Page 326 and 327:
CHAPTER 18 ■ RPC The SimpleXMLRPC
Page 328 and 329:
CHAPTER 18 ■ RPC Traceback (most
Page 330 and 331:
CHAPTER 18 ■ RPC 8.0 If this
Page 332 and 333:
CHAPTER 18 ■ RPC Note that the po
Page 334 and 335:
CHAPTER 18 ■ RPC up being, simply
Page 336 and 337:
CHAPTER 18 ■ RPC such as Python i
Page 338 and 339:
CHAPTER 18 ■ RPC • Google Proto
Page 340 and 341:
■ INDEX mod_python, 194 Qpid, 131
Page 342 and 343:
■ INDEX Common Gateway Interface.
Page 344 and 345:
■ INDEX international characters
Page 346 and 347:
■ INDEX front-end web servers, 17
Page 348 and 349:
■ INDEX deleting folders, 260 del
Page 350 and 351:
■ INDEX mechanize, 138, 163 Memca
Page 352 and 353:
■ INDEX pausing terminal output,
Page 354 and 355:
■ INDEX resources. See also RFCs
Page 356 and 357:
■ INDEX shutdown(), 48 shutting d
Page 358 and 359:
■ INDEX terminals, 270-74 bufferi
Page 360 and 361:
■ INDEX ■ V validating cached r
show all

Foundations of Python Network Programming 978-1-4302-3004-5

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?