The book provides a comprehensive guide to building network applications with Python.

పుస్తకం పైథాన్తో నెట్‌వర్క్ అప్లికేషన్‌లను రూపొందించడానికి ఒక సమగ్ర మార్గదర్శిని అందిస్తుంది.


This second edition includes updated information and examples.

ఈ రెండవ ఎడిషన్‌లో నవీకరించబడిన సమాచారం మరియు ఉదాహరణలు ఉన్నాయి.


The book is copyrighted by Brandon Rhodes and John Goerzen.

ఈ పుస్తకానికి బ్రాండన్ రోడ్స్ మరియు జాన్ గోర్జన్ కాపీరైట్ కలిగి ఉన్నారు.


No part of this work may be reproduced without permission.

ఈ పనిలో ఏ భాగాన్ని అనుమతి లేకుండా పునరుత్పత్తి చేయకూడదు.


The ISBN numbers are provided for reference.

సూచన కోసం ISBN సంఖ్యలు అందించబడ్డాయి.


The book was printed in the United States of America.

పుస్తకం అమెరికా సంయుక్త రాష్ట్రాల్లో ముద్రించబడింది.


ట్రేడ్‌మార్క్ పేర్లను సంపాదకీయంగా ఉపయోగిస్తారు.


ప్రచురణకర్త అప్రెస్.


The book's source code is available online.

పుస్తకం యొక్క సోర్స్ కోడ్ ఆన్‌లైన్‌లో అందుబాటులో ఉంది.


The book covers topics like UDP sockets and TCP.

పుస్తకం UDP సాకెట్లు మరియు TCP వంటి అంశాలను కవర్ చేస్తుంది.


ఇది సాకెట్ పేర్లు మరియు DNS గురించి కూడా చర్చిస్తుంది.


Network data and network errors are also explained.

నెట్‌వర్క్ డేటా మరియు నెట్‌వర్క్ లోపాలను కూడా వివరిస్తారు.


The book includes information on TLS and SSL.

పుస్తకంలో TLS మరియు SSL గురించిన సమాచారం ఉంది.


Server architecture and design are also discussed.

సర్వర్ ఆర్కిటెక్చర్ మరియు డిజైన్ గురించి కూడా చర్చించబడింది.


The book covers caches, message queues, and map-reduce.

పుస్తకం కాష్‌లు, సందేశ క్యూలు మరియు మ్యాప్-రెడ్యూస్‌ను కవర్ చేస్తుంది.


HTTP, screen scraping, and web applications are also included.

HTTP, స్క్రీన్ స్క్రాపింగ్ మరియు వెబ్ అప్లికేషన్‌లు కూడా చేర్చబడ్డాయి.


E-mail composition and decoding are explained.

ఇ-మెయిల్ కూర్పు మరియు డీకోడింగ్ వివరించబడ్డాయి.


The book also covers SMTP, POP, and IMAP.

పుస్తకం SMTP, POP మరియు IMAP లను కూడా కవర్ చేస్తుంది.


Telnet and SSH are also discussed in the book.

టెల్నెట్ మరియు SSH గురించి కూడా పుస్తకంలో చర్చించబడింది.


పుస్తకం FTP మరియు RPCతో ముగుస్తుంది.


Sockets provide the same idea for the networking realm.

నెట్‌వర్కింగ్ ప్రపంచానికి సాకెట్లు అదే ఆలోచనను అందిస్తాయి.


When you ask for access to a line of communication, you create one of these abstract “socket” objects.

మీరు కమ్యూనికేషన్ లైన్‌ను యాక్సెస్ చేయమని అడిగినప్పుడు, మీరు ఈ అమూర్త “సాకెట్” వస్తువులలో ఒకదాన్ని సృష్టిస్తారు.


Sockets actually are file descriptors, which happen to be connected to network sources of data rather than to data stored on a filesystem.

వాస్తవానికి సాకెట్లు ఫైల్ డిస్క్రిప్టర్లు, ఇవి ఫైల్‌సిస్టమ్‌లో నిల్వ చేయబడిన డేటాకు కాకుండా నెట్‌వర్క్ డేటా మూలాలకు కనెక్ట్ చేయబడతాయి.


This gives them some unusual abilities relative to normal files.

ఇది సాధారణ ఫైల్‌లతో పోలిస్తే వారికి కొన్ని అసాధారణ సామర్థ్యాలను ఇస్తుంది.


Take a look at Listing 2–1, which shows a simple server and client.

ఒక సాధారణ సర్వర్ మరియు క్లయింట్‌ను చూపే జాబితా 2–1ని చూడండి.


You can see already that all sorts of operations are taking place that are drawn from the socket module in the Python Standard Library.

మీరు ఇప్పటికే పైథాన్ స్టాండర్డ్ లైబ్రరీలోని సాకెట్ మాడ్యూల్ నుండి తీసుకోబడిన అన్ని రకాల కార్యకలాపాలు జరుగుతున్నాయని చూడవచ్చు.


ముందుగా సర్వర్‌ను అమలు చేయడానికి ప్రయత్నించండి.


It first created a plain socket with the socket() call.

ఇది మొదట సాకెట్() కాల్‌తో ఒక సాధారణ సాకెట్‌ను సృష్టించింది.


At this point, an exception could be raised if another program is already using that UDP port.

ఈ సమయంలో, మరొక ప్రోగ్రామ్ ఇప్పటికే ఆ UDP పోర్ట్‌ను ఉపయోగిస్తుంటే, ఒక మినహాయింపును పెంచవచ్చు.


I glanced over the list and made the gamble that you, gentle reader, are not running SAP BusinessObjects Polestar.

నేను జాబితాను పరిశీలించాను మరియు మీరు, సున్నితమైన పాఠకుడిగా, SAP బిజినెస్ ఆబ్జెక్ట్స్ పోల్‌స్టార్‌ను అమలు చేయలేదని పందెం కాశాను.


Note that the Python program can always use a socket’s getsockname() method to retrieve the current IP and port.

ప్రస్తుత IP మరియు పోర్ట్‌ను తిరిగి పొందడానికి పైథాన్ ప్రోగ్రామ్ ఎల్లప్పుడూ సాకెట్ యొక్క getsockname() పద్ధతిని ఉపయోగించవచ్చని గమనించండి.


Once the socker has been bound successfully, the server is ready to start receiving requests!

సాకెట్ విజయవంతంగా బంధించబడిన తర్వాత, సర్వర్ అభ్యర్థనలను స్వీకరించడానికి సిద్ధంగా ఉంది!


It enters a loop and repeatedly runs recvfrom().

ఇది ఒక లూప్‌లోకి ప్రవేశిస్తుంది మరియు పదేపదే recvfrom()ని అమలు చేస్తుంది.


So let’s start up our client and see the result.

కాబట్టి మన క్లయింట్‌ను ప్రారంభిద్దాం మరియు ఫలితాన్ని చూద్దాం.


The client code is also shown in Listing 2–1, beneath the test of sys.argv for the string 'client'.

క్లయింట్ కోడ్ జాబితా 2–1లో కూడా చూపబడింది, 'క్లయింట్' స్ట్రింగ్ కోసం sys.argv పరీక్ష క్రింద.


This lets us see that both IP address and port number start as all zeroes.

IP చిరునామా మరియు పోర్ట్ నంబర్ రెండూ సున్నాలుగా ప్రారంభమవుతాయని ఇది మనకు చూడటానికి వీలు కల్పిస్తుంది.


Then the client calls sendto() with both a message and a destination address.

అప్పుడు క్లయింట్ సందేశం మరియు గమ్యస్థాన చిరునామా రెండింటితో sendto()ని పిలుస్తుంది.


So the operating system assigns one automatically.

కాబట్టి ఆపరేటింగ్ సిస్టమ్ ఒకదాన్ని స్వయంచాలకంగా కేటాయిస్తుంది.


Since the client knows that he is expecting a reply from the server, he simply calls the socket’s recv() method.

క్లయింట్ సర్వర్ నుండి సమాధానం వస్తుందని తెలుసుకున్నందున, అతను కేవలం సాకెట్ యొక్క recv() పద్ధతిని పిలుస్తాడు.


Each time the client runs, a complete round-trip of request and reply is passing between two UDP sockets.

క్లయింట్ ప్రతిసారీ నడుస్తున్నప్పుడు, అభ్యర్థన మరియు ప్రత్యుత్తరం యొక్క పూర్తి రౌండ్-ట్రిప్ రెండు UDP సాకెట్‌ల మధ్య వెళుతుంది.


The client will wait forever for a response.

క్లయింట్ ప్రతిస్పందన కోసం ఎప్పటికీ వేచి ఉంటుంది.


Try running the client from Listing 2–1 in one window.

ఒక విండోలో జాబితా 2–1 నుండి క్లయింట్‌ను అమలు చేయడానికి ప్రయత్నించండి.


The client is now waiting—perhaps forever—for a response.

క్లయింట్ ఇప్పుడు వేచి ఉంది— బహుశా ఎప్పటికీ— ప్రతిస్పందన కోసం.


But what if we nefariously try sending it back a packet from a different server, instead?

కానీ మనం మోసపూరితంగా వేరే సర్వర్ నుండి ప్యాకెట్‌ను తిరిగి పంపడానికి ప్రయత్నిస్తే ఏమిటి?


Even though this Python session has grabbed a completely wild port number, which looks nothing like 1060 nor is even close, the client happily accepts this fake reply as an answer and prints it to the screen!

ఈ పైథాన్ సెషన్ పూర్తిగా అస్థిరమైన పోర్ట్ నంబర్‌ను పొందినప్పటికీ, ఇది 1060 లాగా లేదు లేదా దగ్గరగా కూడా లేదు, క్లయింట్ ఈ నకిలీ సమాధానాన్ని సంతోషంగా అంగీకరిస్తుంది మరియు దానిని తెరపై ముద్రిస్తుంది!


It turns out that our first client accepts answers from anywhere.

మా మొదటి క్లయింట్ ఎక్కడి నుండైనా సమాధానాలను అంగీకరిస్తుందని తేలింది.


If a real UDP client were written this way, and an attacker or malcontent knew that we were running it, then they could send packets to its UDP port.

ఒకవేళ నిజమైన UDP క్లయింట్ ఈ విధంగా వ్రాయబడితే, మరియు ఒక దాడి చేసే వ్యక్తి లేదా అసంతృప్తి చెందిన వ్యక్తి మేము దానిని నడుపుతున్నామని తెలిస్తే, వారు దాని UDP పోర్ట్‌కు ప్యాకెట్‌లను పంపవచ్చు.


This is because of the second, less-obvious effect of using connect() to select a UDP socket’s destination.

దీనికి కారణం connect()ని ఉపయోగించడం వల్ల కలిగే రెండవ, తక్కువ స్పష్టమైన ప్రభావం UDP సాకెట్ యొక్క గమ్యాన్ని ఎంచుకోవడం.


You can use sendto() and direct each outgoing packet to a specific destination.

మీరు sendto()ని ఉపయోగించవచ్చు మరియు ప్రతి అవుట్‌గోయింగ్ ప్యాకెట్‌ను నిర్దిష్ట గమ్యస్థానానికి పంపవచ్చు.


You can connect() your socket right after creating it.

మీరు సాకెట్‌ను సృష్టించిన వెంటనే connect() చేయవచ్చు.


After you have connected a UDP socket using connect(), you can use the socket’s getpeername() method.

connect()ని ఉపయోగించి మీరు UDP సాకెట్‌ను కనెక్ట్ చేసిన తర్వాత, మీరు సాకెట్ యొక్క getpeername() పద్ధతిని ఉపయోగించవచ్చు.


Be careful about calling this on a socket that is not yet connected.

ఇంకా కనెక్ట్ చేయని సాకెట్‌లో దీన్ని కాల్ చేసేటప్పుడు జాగ్రత్త వహించండి.


First, doing a connect() on a UDP socket, of type SOCK_DGRAM, does not send any information across the network.

ముందుగా, SOCK_DGRAM రకం యొక్క UDP సాకెట్‌పై connect() చేయడం వలన నెట్‌వర్క్ ద్వారా ఎటువంటి సమాచారం పంపబడదు.


Second, doing a connect(), or even filtering out unwanted packets yourself using the return address, is not a form of security!

రెండవది, కనెక్ట్ చేయడం లేదా రిటర్న్ చిరునామాను ఉపయోగించి మీరు కోరుకోని ప్యాకెట్‌లను ఫిల్టర్ చేయడం భద్రత కాదు!


If there is someone on the network who is really malicious, it is usually easy enough for their computer to forge packets with the server’s return address.

నెట్‌వర్క్‌లో నిజంగా హానికరమైన వ్యక్తి ఉంటే, వారి కంప్యూటర్ సర్వర్ యొక్క రిటర్న్ చిరునామాతో ప్యాకెట్‌లను ఫోర్జ్ చేయడం సాధారణంగా సులభం.


Sending packets with another computer’s return address is called spoofing.

మరొక కంప్యూటర్ యొక్క రిటర్న్ చిరునామాతో ప్యాకెట్‌లను పంపడాన్ని స్ఫూఫింగ్ అంటారు.


The messages sent in both Listings 2–1 and 2–2 were simple text.

జాబితాలు 2–1 మరియు 2–2 రెండింటిలోనూ పంపిన సందేశాలు సాధారణ వచనం.


But if you should ever design a scheme of your own for doing UDP requests and responses, you should strongly consider adding a sequence number to each request.

కానీ మీరు UDP అభ్యర్థనలు మరియు ప్రతిస్పందనలను చేయడానికి మీ స్వంత పథకాన్ని రూపొందించినట్లయితే, మీరు ప్రతి అభ్యర్థనకు సీక్వెన్స్ నంబర్‌ను జోడించడాన్ని తీవ్రంగా పరిగణించాలి.


అభ్యర్థన IDలు మిమ్మల్ని దాని నుండి రక్షిస్తాయి.


We will now explore, in detail, how the sophisticated Google Maps service is actually just the top layer of a network stack.

ఇప్పుడు, అధునాతన Google Maps సేవ వాస్తవానికి నెట్‌వర్క్ స్టాక్ యొక్క టాప్ లేయర్ మాత్రమే అని వివరంగా చూద్దాం.


What if we had to build a client for Google’s Maps API on our own?

మన స్వంతంగా Google యొక్క Maps API కోసం ఒక క్లయింట్‌ను నిర్మించాల్సి వస్తే ఏమిటి?


Fetching a JSON Document from the Google Maps URL

Google Maps URL నుండి JSON డాక్యుమెంట్‌ను పొందడం


Running this Python program returns an answer quite similar to that of our first script.

ఈ పైథాన్ ప్రోగ్రామ్‌ను అమలు చేయడం వలన మన మొదటి స్క్రిప్ట్‌కు సమానమైన సమాధానం వస్తుంది.


In search2.py, we have stepped one rung down the ladder.

search2.py లో, మేము మెట్లపై ఒక మెట్టు దిగాము.


Unless you look very closely at this code, you might not even see that it’s asking about a mailing address at all!

మీరు ఈ కోడ్‌ను చాలా దగ్గరగా పరిశీలించకపోతే, ఇది మెయిలింగ్ చిరునామా గురించి అడుగుతుందని కూడా మీకు తెలియకపోవచ్చు!


If you want to read their documentation, by the way, you can find the Google Maps API described here.

మీరు వారి డాక్యుమెంటేషన్‌ను చదవాలనుకుంటే, మీరు Google Maps API ని ఇక్కడ చూడవచ్చు.


The other parameters indicate the format in which we want the output returned.

ఇతర పారామితులు మనం అవుట్‌పుట్‌ను ఏ ఫార్మాట్‌లో తిరిగి పొందాలనుకుంటున్నామో సూచిస్తాయి.


The search2.py script, then, does exactly the same thing as the first one.

అయితే, search2.py స్క్రిప్ట్ మొదటి దానితో సమానంగానే చేస్తుంది.


This is a common difference when you step down a level from one layer of a network stack to the layer beneath it.

నెట్‌వర్క్ స్టాక్ యొక్క ఒక లేయర్ నుండి దాని క్రింది లేయర్‌కు ఒక స్థాయిని తగ్గించినప్పుడు ఇది ఒక సాధారణ వ్యత్యాసం.


But the real reason that a URL can be used to fetch a document, of course, is that the URL is a kind of a recipe that describes where to find—and how to fetch—a given document on the web.

కానీ, వాస్తవానికి, URL ని డాక్యుమెంట్‌ను పొందడానికి ఉపయోగించటానికి అసలు కారణం ఏమిటంటే, URL అనేది వెబ్‌లో ఇచ్చిన డాక్యుమెంట్‌ను ఎక్కడ కనుగొనాలో మరియు ఎలా పొందాలి అని వివరించే ఒక రకమైన రెసిపీ.


The URL consists of the name of a protocol, followed by the name of the machine where the document lives, and finishes with the path that names document on that machine.

URL ఒక ప్రోటోకాల్ పేరుతో మొదలవుతుంది, తరువాత డాక్యుమెంట్ ఉన్న మెషిన్ పేరుతో, ఆపై ఆ మెషిన్ లోని డాక్యుమెంట్‌ను సూచించే మార్గంతో ముగుస్తుంది.


We will learn more about it in Section 2 of this book.

ఈ పుస్తకం యొక్క విభాగం 2 లో దీని గురించి మరింత తెలుసుకుంటాము.


What, do you think, would it look like if we were to strip that layer of magic off—what if we wanted to use HTTP to directly fetch the result?

ఆ మాయాజాలాన్ని తీసివేస్తే ఎలా ఉంటుందో మీరు ఏమనుకుంటున్నారు—మనం ఫలితాన్ని నేరుగా పొందడానికి HTTP ని ఉపయోగించాలనుకుంటే ఏమిటి?


In this listing, all references to the idea of a URL have disappeared.

ఈ జాబితాలో, URL ఆలోచనకు సంబంధించిన అన్ని సూచనలు కనుమరుగయ్యాయి.


Instead, we are here directly manipulating the HTTP protocol.

బదులుగా, మేము ఇక్కడ నేరుగా HTTP ప్రోటోకాల్‌ను మారుస్తున్నాము.


The result of running the program, however, is much the same as for the programs shown previously.

అయితే, ప్రోగ్రామ్‌ను అమలు చేయడం వల్ల వచ్చిన ఫలితం ఇంతకు ముందు చూపిన ప్రోగ్రామ్‌ల మాదిరిగానే ఉంటుంది.


As we will see throughout this book, HTTP is just one of many protocols for which the Python Standard Library provides a built-in implementation.

ఈ పుస్తకం అంతటా మనం చూసినట్లుగా, పైథాన్ స్టాండర్డ్ లైబ్రరీ అంతర్నిర్మిత అమలును అందించే అనేక ప్రోటోకాల్‌లలో HTTP ఒకటి.


But, of course, HTTP cannot simply send data between two machines using thin air.

కానీ, వాస్తవానికి, HTTP గాలిని ఉపయోగించి రెండు కంప్యూటర్ల మధ్య డేటాను పంపించలేరు.


In every previous program listing, we were using a Python library—written in Python itself—that knows how to speak a complicated network protocol on our behalf.

ప్రతి మునుపటి ప్రోగ్రామ్ జాబితాలో, మేము ఒక పైథాన్ లైబ్రరీని ఉపయోగిస్తున్నాము—పైథాన్ లోనే వ్రాయబడింది—ఇది మన తరపున ఒక సంక్లిష్టమైన నెట్‌వర్క్ ప్రోటోకాల్‌ను ఎలా మాట్లాడాలో తెలుసు.


You are even likely to see some of these private addresses in your own home.

మీ స్వంత ఇంట్లో కూడా మీరు ఈ ప్రైవేట్ చిరునామాలను చూసే అవకాశం ఉంది.


Your Linksys wireless router or DSL modem will often assign IP addresses from one of these private ranges to your home computers and laptops.

మీ Linksys వైర్‌లెస్ రూటర్ లేదా DSL మోడెమ్ తరచుగా మీ హోమ్ కంప్యూటర్లు మరియు ల్యాప్‌టాప్‌లకు ఈ ప్రైవేట్ శ్రేణులలో ఒకదాని నుండి IP చిరునామాలను కేటాయిస్తుంది.


Routing So, operating systems that implement the Internet protocol allow programs to send messages whose destinations IP addresses—say, 8.8.4.4—and to deliver each packet, the operating system has to decide how to transmit it using one of the physical networks to which the machine is connected.

రౌటింగ్ కాబట్టి, ఇంటర్నెట్ ప్రోటోకాల్‌ను అమలు చేసే ఆపరేటింగ్ సిస్టమ్‌లు ప్రోగ్రామ్‌లు సందేశాలను పంపడానికి అనుమతిస్తాయి, వాటి గమ్యస్థాన IP చిరునామాలు—అంటే, 8.8.4.4—మరియు ప్రతి ప్యాకెట్‌ను అందించడానికి, ఆపరేటింగ్ సిస్టమ్ దానిని మెషిన్ కనెక్ట్ చేయబడిన భౌతిక నెట్‌వర్క్‌లలో ఒకదానిని ఉపయోగించి ఎలా ప్రసారం చేయాలో నిర్ణయించుకోవాలి.


This decision—the decision of where to send each packet, based on the IP address that is its destination—is called routing.

ఈ నిర్ణయం—ప్రతి ప్యాకెట్‌ను ఎక్కడికి పంపాలి అనే నిర్ణయం, దాని గమ్యస్థానంగా ఉన్న IP చిరునామా ఆధారంగా—రౌటింగ్ అని పిలువబడుతుంది.


Most, or perhaps all, of the Python code you write during your career will be running on hosts out at the very edge of the Internet.

మీ కెరీర్‌లో మీరు రాసే చాలా లేదా బహుశా మొత్తం పైథాన్ కోడ్ ఇంటర్నెట్ యొక్క అంచున ఉన్న హోస్ట్‌లలో నడుస్తుంది.


For such machines, routing becomes a quite simple decision.

అటువంటి యంత్రాల కోసం, రౌటింగ్ చాలా సులభమైన నిర్ణయంగా మారుతుంది.


If the IP address looks like 127.*.*.*, then the operating system knows that the packet is destined for another application running on the same machine.

IP చిరునామా 127.*.*.*లాగా కనిపిస్తే, ప్యాకెట్ అదే మెషీన్‌లో నడుస్తున్న మరొక అప్లికేషన్ కోసం ఉద్దేశించబడిందని ఆపరేటింగ్ సిస్టమ్ తెలుసుకుంటుంది.


Otherwise, your machine forwards the packet to a gateway machine that connects your local subnet to the rest of the Internet.

లేకపోతే, మీ మెషిన్ ప్యాకెట్‌ను మీ స్థానిక సబ్‌నెట్‌ను ఇంటర్నెట్‌కు మిగిలిన వాటికి కనెక్ట్ చేసే గేట్‌వే మెషిన్‌కు ఫార్వార్డ్ చేస్తుంది.


It will then be up to the gateway machine to decide where to send the packet after that.

ఆ తర్వాత ప్యాకెట్‌ను ఎక్కడికి పంపించాలో గేట్‌వే మెషిన్ నిర్ణయించుకుంటుంది.


You can imagine that routing decisions are much more complex for the dedicated network devices that form the Internet’s backbone!

ఇంటర్నెట్ యొక్క బ్యాక్‌బోన్‌ను ఏర్పరుచుకునే ప్రత్యేక నెట్‌వర్క్ పరికరాల కోసం రౌటింగ్ నిర్ణయాలు చాలా సంక్లిష్టంగా ఉంటాయని మీరు ఊహించవచ్చు!


There, on the hubs that connect entire continents, elaborate routing tables have to be constructed, consulted, and constantly updated in order to know that packets destined for Google go in one direction, but packets directed to a Yahoo IP address go in another, and that packets directed to your machine go in yet another.

అక్కడ, మొత్తం ఖండాలను కలిపే కేంద్రాలలో, Google కోసం ఉద్దేశించిన ప్యాకెట్‌లు ఒక దిశలో వెళతాయని తెలుసుకోవడానికి విస్తృతమైన రౌటింగ్ పట్టికలను నిర్మించాలి, సంప్రదించాలి మరియు నిరంతరం అప్‌డేట్ చేయాలి, అయితే Yahoo IP చిరునామాకు నిర్దేశించిన ప్యాకెట్‌లు మరొకదానికి వెళతాయి మరియు మీ మెషిన్‌కు నిర్దేశించిన ప్యాకెట్‌లు మరొకదానికి వెళతాయి.


But it is very rare for Python applications to run on Internet backbone routers, so the simpler routing situation just outlined is nearly always the one you will see in action.

కానీ ఇంటర్నెట్ బ్యాక్‌బోన్ రూటర్‌లలో పైథాన్ అప్లికేషన్‌లు అమలు చేయడం చాలా అరుదు, కాబట్టి ఇప్పుడే వివరించిన సాధారణ రౌటింగ్ పరిస్థితి దాదాపు ఎల్లప్పుడూ మీరు చర్యలో చూసేది.


To illustrate the idea of a subnet, all of whose hosts share the same IP address prefix, I have been writing the prefix followed by asterisks for the parts of the address that could vary.

సబ్‌నెట్ ఆలోచనను వివరించడానికి, దాని హోస్ట్‌లన్నీ ఒకే IP చిరునామా ఉపసర్గను కలిగి ఉంటాయి, చిరునామాలోని మారగల భాగాల కోసం నేను ఉపసర్గను నక్షత్రాలతో వ్రాస్తున్నాను.


Instead, subnets are specified by combining an IP address with a mask that indicates how many of its most significant bits have to match to make a host belong to that subnet.

బదులుగా, సబ్‌నెట్‌లు ఒక IP చిరునామాను మాస్క్‌తో కలిపి పేర్కొనబడతాయి, ఇది హోస్ట్ ఆ సబ్‌నెట్‌కు చెందినదిగా చేయడానికి ఎన్ని ముఖ్యమైన బిట్‌లు సరిపోలాలి అని సూచిస్తుంది.


If you keep in mind that every byte in an IP address represents eight bits of binary data, then you will be able to read subnet numbers very easily.

IP చిరునామాలోని ప్రతి బైట్ బైనరీ డేటా యొక్క ఎనిమిది బిట్‌లను సూచిస్తుందని మీరు గుర్తుంచుకుంటే, మీరు సబ్‌నెట్ నంబర్‌లను చాలా సులభంగా చదవగలరు.


This pattern, which describes the IP address range that we discussed previously, which is reserved for the local host, specifies that the first eight bits (one byte) must match the number 127, and that the remaining 24 bits (three bytes) can have any value they want.

ఈ నమూనా, మనం ఇంతకు ముందు చర్చించిన IP చిరునామా పరిధిని వివరిస్తుంది, ఇది స్థానిక హోస్ట్ కోసం రిజర్వ్ చేయబడింది, మొదటి ఎనిమిది బిట్‌లు (ఒక బైట్) 127 నంబర్‌తో సరిపోలాలి మరియు మిగిలిన 24 బిట్‌లు (మూడు బైట్‌లు) వారికి కావలసిన ఏదైనా విలువను కలిగి ఉండవచ్చు అని పేర్కొంది.


This pattern will match any IP address that belongs in the private 192.168 range, because the first 16 bits must match perfectly.

ఈ నమూనా ప్రైవేట్ 192.168 పరిధికి చెందిన ఏదైనా IP చిరునామాతో సరిపోతుంది, ఎందుకంటే మొదటి 16 బిట్‌లు ఖచ్చితంగా సరిపోలాలి.


ఇది 256 ప్రత్యేక చిరునామాలను వదిలివేస్తుంది.


Typically, the .0 address is used as the name of the subnet, and the .255 address is used to create a “broadcast packet” that addresses all of the hosts on the subnet (as we will see in the next chapter), which leaves 254 addresses free to actually be assigned to computers.

సాధారణంగా, .0 చిరునామాను సబ్‌నెట్ పేరుగా ఉపయోగిస్తారు మరియు .255 చిరునామాను సబ్‌నెట్‌లోని అన్ని హోస్ట్‌లను పరిష్కరించే “ప్రసార ప్యాకెట్”ను రూపొందించడానికి ఉపయోగిస్తారు (మేము తదుపరి అధ్యాయంలో చూస్తాము), ఇది కంప్యూటర్‌లకు కేటాయించడానికి 254 చిరునామాలను ఉచితంగా ఉంచుతుంది.


In nearly all cases, your Python code will simply rely on its host operating system to make packet routing choices correctly—just as it lets the operating system resolve host names to IP addresses in the first place.

దాదాపు అన్ని సందర్భాల్లో, మీ పైథాన్ కోడ్ ప్యాకెట్ రౌటింగ్ ఎంపికలను సరిగ్గా చేయడానికి దాని హోస్ట్ ఆపరేటింగ్ సిస్టమ్‌పై ఆధారపడుతుంది—ఆపరేటింగ్ సిస్టమ్ హోస్ట్ పేర్లను మొదట IP చిరునామాలకు పరిష్కరించడానికి అనుమతించినట్లే.


Turning on broadcast for a UDP socket does not disable or change its normal ability to send and receive specifically addressed packets.

ఒక UDP సాకెట్ కోసం ప్రసారం ఆన్ చేయడం వలన నిర్దిష్టంగా పరిష్కరించబడిన ప్యాకెట్‌లను పంపడానికి మరియు స్వీకరించడానికి దాని సాధారణ సామర్థ్యాన్ని నిలిపివేయదు లేదా మార్చదు.


The magic happens when you view the settings for your local network, and use its IP “broadcast address” as the destination for the client.

మీరు మీ స్థానిక నెట్‌వర్క్ కోసం సెట్టింగ్‌లను చూసినప్పుడు మరియు దాని IP “ప్రసార చిరునామా”ని క్లయింట్ కోసం గమ్యస్థానంగా ఉపయోగించినప్పుడు మాయాజాలం జరుగుతుంది.


First bring up one or two servers on your network, using commands like the following: $ python udp_broadcast.py server Listening for broadcasts at ('0.0.0.0', 1060)

ముందుగా, కింది ఆదేశాలను ఉపయోగించి మీ నెట్‌వర్క్‌లో ఒకటి లేదా రెండు సర్వర్‌లను తీసుకురండి: $ python udp_broadcast.py server ('0.0.0.0', 1060) వద్ద ప్రసారాల కోసం వినండి


You will see that only one server gets each message: $ python udp_broadcast.py client 192.168.5.10

ప్రతి సందేశాన్ని ఒకే సర్వర్ పొందుతుందని మీరు చూస్తారు: $ python udp_broadcast.py client 192.168.5.10


But when you use the local network’s broadcast address, suddenly you will see that all of the broadcast servers get the packet at the same time!

కానీ మీరు స్థానిక నెట్‌వర్క్ యొక్క ప్రసార చిరునామాను ఉపయోగించినప్పుడు, ప్రసార సర్వర్లన్నీ ఒకే సమయంలో ప్యాకెట్‌ను పొందుతాయని మీరు అకస్మాత్తుగా చూస్తారు!


In case your operating system makes it difficult to determine the broadcast address, and you do not mind doing a broadcast out of every single network port of your host, Python lets you use the special hostname '<broadcast>' when sending with a UDP socket.

మీ ఆపరేటింగ్ సిస్టమ్ ప్రసార చిరునామాను గుర్తించడం కష్టతరం చేస్తే మరియు మీ హోస్ట్ యొక్క ప్రతి నెట్‌వర్క్ పోర్ట్ నుండి ప్రసారం చేయడానికి మీకు అభ్యంతరం లేకపోతే, UDP సాకెట్‌తో పంపేటప్పుడు ప్రత్యేక హోస్ట్ పేరు '<broadcast>'ని ఉపయోగించడానికి Python మిమ్మల్ని అనుమతిస్తుంది.


Be careful to quote that name when passing it to our client, since the < and > characters are quite special to any normal POSIX shell: $ python udp_broadcast.py client "<broadcast>"

ఆ పేరును మా క్లయింట్‌కు పంపేటప్పుడు జాగ్రత్తగా ఉదహరించండి, ఎందుకంటే < మరియు > అక్షరాలు ఏదైనా సాధారణ POSIX షెల్‌కు చాలా ప్రత్యేకమైనవి: $ python udp_broadcast.py client "<broadcast>"


You might think that UDP would be very efficient for sending small messages.

చిన్న సందేశాలను పంపడానికి UDP చాలా సమర్థవంతంగా ఉంటుందని మీరు అనుకోవచ్చు.


Actually, UDP is efficient only if your host ever only sends one message at a time, then waits for a response.

వాస్తవానికి, మీ హోస్ట్ ఒకేసారి ఒక సందేశాన్ని మాత్రమే పంపితే, అప్పుడు ప్రతిస్పందన కోసం ఎదురు చూస్తే మాత్రమే UDP సమర్థవంతంగా ఉంటుంది.


There are two good reasons to use UDP: Because you are implementing a protocol that already exists, and it uses UDP.

UDPని ఉపయోగించడానికి రెండు మంచి కారణాలు ఉన్నాయి: మీరు ఇప్పటికే ఉన్న ప్రోటోకాల్‌ను అమలు చేస్తున్నందున మరియు ఇది UDPని ఉపయోగిస్తుంది.


The User Data Protocol, UDP, lets user-level programs send individual packets across an IP network.

యూజర్ డేటా ప్రోటోకాల్, UDP, వినియోగదారు-స్థాయి ప్రోగ్రామ్‌లు IP నెట్‌వర్క్ ద్వారా వ్యక్తిగత ప్యాకెట్‌లను పంపడానికి అనుమతిస్తుంది.


The POSIX network stack gives you access to UDP through the idea of a “socket,” which is a communications endpoint that can sit at an IP address and UDP port number—these two things together are called the socket’s “name”—and send and receive UDP packets.

POSIX నెట్‌వర్క్ స్టాక్ మీకు “సాకెట్” అనే ఆలోచన ద్వారా UDPని యాక్సెస్ చేయడానికి అందిస్తుంది, ఇది ఒక కమ్యూనికేషన్ ఎండ్‌పాయింట్, ఇది IP చిరునామా మరియు UDP పోర్ట్ నంబర్‌తో కూర్చుని ఉంటుంది—ఈ రెండు విషయాలను కలిపి సాకెట్ యొక్క “పేరు” అంటారు—మరియు UDP ప్యాకెట్‌లను పంపండి మరియు స్వీకరించండి.


Clients have to compensate for this by being willing to re-transmit a request until they receive a reply.

ప్రత్యుత్తరం వచ్చే వరకు అభ్యర్థనను తిరిగి ప్రసారం చేయడానికి సిద్ధంగా ఉండటం ద్వారా క్లయింట్‌లు దీనిని భర్తీ చేయాలి.


Request IDs are crucial to combat the problem of reply duplication, where a reply you thought was lost arrives later after all and could be mistaken for the reply to your current question.

ప్రత్యుత్తరం నకిలీ సమస్యను ఎదుర్కోవడానికి అభ్యర్థన IDలు చాలా కీలకం, ఇక్కడ మీరు కోల్పోయారని అనుకున్న ప్రత్యుత్తరం తరువాత వస్తుంది మరియు మీ ప్రస్తుత ప్రశ్నకు ప్రత్యుత్తరంగా పొరపాటు పడవచ్చు.


Among the socket options available for UDP sockets, the most powerful is broadcast, which lets you send packets to every host on your subnet without having to send to each host individually.

UDP సాకెట్‌ల కోసం అందుబాటులో ఉన్న సాకెట్ ఎంపికలలో, అత్యంత శక్తివంతమైనది ప్రసారం, ఇది ప్రతి హోస్ట్‌కు వ్యక్తిగతంగా పంపకుండా మీ సబ్‌నెట్‌లోని ప్రతి హోస్ట్‌కు ప్యాకెట్‌లను పంపడానికి మిమ్మల్ని అనుమతిస్తుంది.


Rather than running very slowly in lock-step by needing every packet to be acknowledged before it sends the next one, TCP sends whole bursts of packets at a time before expecting a response.

తదుపరి ప్యాకెట్‌ను పంపడానికి ముందు ప్రతి ప్యాకెట్‌ను గుర్తించాల్సిన అవసరం ద్వారా చాలా నెమ్మదిగా లాక్-స్టెప్‌లో నడుస్తున్న బదులు, TCP ప్రతిస్పందనను ఆశించే ముందు ఒకేసారి ప్యాకెట్‌ల మొత్తాన్ని పంపుతుంది.


The TCP implementation on the receiving end can regulate the window size of the transmitting end, and thus slow or pause the connection.

స్వీకరించే చివరన ఉన్న TCP అమలు ప్రసారం చేసే చివర యొక్క విండో పరిమాణాన్ని నియంత్రించగలదు మరియు తద్వారా కనెక్షన్‌ను నెమ్మదిస్తుంది లేదా పాజ్ చేస్తుంది.


This is impossible with TCP, and so UDP is often the foundation of live-streaming multimedia over the Internet.

ఇది TCPతో అసాధ్యం, కాబట్టి ఇంటర్నెట్‌లో లైవ్-స్ట్రీమింగ్ మల్టీమీడియాకు UDP తరచుగా ఆధారం.


As we saw in the previous chapter, it takes only a single socket to speak UDP: a server can open a datagram port and then receive packets from thousands of different clients.

మునుపటి అధ్యాయంలో మనం చూసినట్లుగా, UDP మాట్లాడటానికి ఒకే సాకెట్ మాత్రమే పడుతుంది: ఒక సర్వర్ డేటాగ్రామ్ పోర్ట్‌ను తెరవగలదు మరియు వేలాది మంది వేర్వేరు క్లయింట్‌ల నుండి ప్యాకెట్‌లను స్వీకరించగలదు.


But with a stateful stream protocol like TCP, the connect() call becomes the fundamental act upon which all other network communication hinges.

కానీ TCP వంటి స్టేట్‌ఫుల్ స్ట్రీమ్ ప్రోటోకాల్‌తో, కనెక్ట్() కాల్ అన్ని ఇతర నెట్‌వర్క్ కమ్యూనికేషన్ ఆధారపడే ప్రాథమిక చర్యగా మారుతుంది.


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.

మీ అప్లికేషన్ డొమైన్ పేరును పరిష్కరించడానికి DNSని మొదటి ఎంపికగా ఉపయోగిస్తే, మీ సిస్టమ్‌లో ప్రతిచోటా పనిచేసే కొన్ని కంప్యూటర్ పేర్లు—వాటి బ్రౌజర్‌లో, ఫైల్ షేర్ పేర్లలో మొదలైనవి—మీరు మీ అప్లికేషన్‌ను ఉపయోగిస్తున్నప్పుడు అకస్మాత్తుగా పని చేయవు, ఎందుకంటే మీరు WINS లేదా /etc/hosts వంటి విధానాలకు వాయిదా వేయడం లేదు, ఆపరేటింగ్ సిస్టమ్ చేస్తుంది.


The DNS is often not the only way that a system gets name information.

DNS తరచుగా సిస్టమ్ పేరు సమాచారాన్ని పొందే ఏకైక మార్గం కాదు.


The local machine probably has a cache of recently queried domain names that might already know about the host whose IP address you need.

స్థానిక మెషీన్ ఇటీవల ప్రశ్నించబడిన డొమైన్ పేర్ల కాష్‌ని కలిగి ఉండవచ్చు, మీకు అవసరమైన హోస్ట్ యొక్క IP చిరునామా గురించి ఇది ఇప్పటికే తెలిసి ఉండవచ్చు.


If you try speaking DNS yourself to answer your query, you will be duplicating work that has already been done.

మీరు మీ ప్రశ్నలకు సమాధానం ఇవ్వడానికి DNSని మీరే మాట్లాడటానికి ప్రయత్నిస్తే, ఇప్పటికే చేసిన పనిని మీరు నకిలీ చేస్తారు.


The system on which your Python script is running already knows about the local domain nameservers.

మీ పైథాన్ స్క్రిప్ట్ నడుస్తున్న సిస్టమ్ ఇప్పటికే స్థానిక డొమైన్ నేమ్‌సర్వర్‌ల గురించి తెలుసు.


To crank up DNS right inside your Python program, you will have to learn how to query your particular operating system for this information.

మీ పైథాన్ ప్రోగ్రామ్‌లో DNSని పెంచడానికి, ఈ సమాచారం కోసం మీ నిర్దిష్ట ఆపరేటింగ్ సిస్టమ్‌ను ఎలా ప్రశ్నించాలో మీరు తెలుసుకోవాలి.


If you do not use the local DNS server, then you will not be able to benefit from its own cache.

మీరు స్థానిక DNS సర్వర్‌ను ఉపయోగించకపోతే, మీరు దాని స్వంత కాష్ నుండి ప్రయోజనం పొందలేరు.


From time to time, adjustments are made to the world DNS infrastructure.

సమయం నుండి సమయానికి, ప్రపంచ DNS మౌలిక సదుపాయాలకు సర్దుబాట్లు చేయబడతాయి.


If your program makes raw DNS calls of its own, then you will have to follow these changes yourself.

మీ ప్రోగ్రామ్ దాని స్వంత ముడి DNS కాల్‌లు చేస్తే, మీరు ఈ మార్పులను మీరే అనుసరించాలి.


Finally, note that Python does not come with any DNS facilities built into the Standard Library.

చివరగా, పైథాన్ స్టాండర్డ్ లైబ్రరీలో నిర్మించిన DNS సౌకర్యాలతో రాదని గమనించండి.


There is, however, a solid and legitimate reason to make a DNS call from Python: because you are a mail server.

అయితే, పైథాన్ నుండి DNS కాల్ చేయడానికి ఒక ఘనమైన మరియు చట్టబద్ధమైన కారణం ఉంది: ఎందుకంటే మీరు మెయిల్ సర్వర్.


We will focus on the slightly more popular distribution, pydns.

మేము కొంచెం ఎక్కువ ప్రజాదరణ పొందిన పంపిణీ, pydns పై దృష్టి పెడతాము.


It makes a DNS package available for you to import.

ఇది దిగుమతి చేసుకోవడానికి మీకు DNS ప్యాకేజీని అందుబాటులో ఉంచుతుంది.


Both distributions have seen updates within the past year.

గత సంవత్సరంలో రెండు పంపిణీలు నవీకరణలను చూశాయి.


Neither project provides code that knows how to “start from scratch” and begin a query with a search of the Internet root domain nameservers!

ఏ ప్రాజెక్ట్ కూడా


Your Python interpreter will then gain the ability to run our first DNS program listing.

అప్పుడు మీ పైథాన్ ఇంటర్‌ప్రెటర్ మా మొదటి DNS ప్రోగ్రామ్ జాబితాను అమలు చేసే సామర్థ్యాన్ని పొందుతుంది.


Neither package seems to have any real documentation.

ఏ ప్యాకేజీకి నిజమైన డాక్యుమెంటేషన్ ఉన్నట్లు అనిపించదు.


As you can see from the program, each “answer” in the reply that has been returned is represented by a dictionary in pydns.

మీరు ప్రోగ్రామ్ నుండి చూడగలిగినట్లుగా, తిరిగి వచ్చిన ప్రతిస్పందనలోని ప్రతి “సమాధానం” pydnsలో నిఘంటువు ద్వారా సూచించబడుతుంది.


మేము వెతికిన పేరు.


Sending e-mail to a domain is a completely different act from trying to make an HTTP or SSH connection to a domain.

డొమైన్‌కు ఇమెయిల్ పంపడం అనేది డొమైన్‌కు HTTP లేదా SSH కనెక్షన్‌ను చేయడానికి ప్రయత్నించడం కంటే పూర్తిగా భిన్నమైన చర్య.


The client and server simply sent their messages, and then could close their sockets separately without needing to do any further checks.

క్లయింట్ మరియు సర్వర్ వారి సందేశాలను పంపారు, ఆ తర్వాత ఎలాంటి తనిఖీలు చేయకుండానే వారి సాకెట్‌లను విడిగా మూసివేయవచ్చు.


But in Listing 3–2, the client sends—and thus the server also processes and sends back—an arbitrary amount of data whose length is not decided until the user enters a number of bytes on the command line.

కానీ జాబితా 3–2లో, క్లయింట్ పంపుతుంది—అలాగే సర్వర్ కూడా ప్రాసెస్ చేసి తిరిగి పంపుతుంది—వినియోగదారుడు కమాండ్ లైన్‌లో ఎన్ని బైట్‌లను నమోదు చేసే వరకు నిర్ణయించబడని డేటా మొత్తాన్ని.


The solution is to “half-close” the socket—that is, to permanently shut down communication in one direction but without destroying the socket itself—so that the server can no longer read any data, but can still send any remaining reply back in the other direction, which will still be open.

పరిష్కారం ఏమిటంటే సాకెట్‌ను “అర్ధ-మూసివేయడం”—అంటే, ఒక దిశలో కమ్యూనికేషన్‌ను శాశ్వతంగా మూసివేయడం, కానీ సాకెట్‌ను నాశనం చేయకుండా—అందువల్ల సర్వర్ ఇకపై ఎలాంటి డేటాను చదవలేకపోతుంది, కానీ మిగిలిన ప్రత్యుత్తరాన్ని ఇతర దిశలో పంపవచ్చు, ఇది ఇప్పటికీ తెరిచే ఉంటుంది.


SHUT_WR: This is the most common value used, since in most cases a program knows when its own output is finished but not about when its conversation partner will be done.

SHUT_WR: ఇది సాధారణంగా ఉపయోగించే విలువ, ఎందుకంటే చాలా సందర్భాల్లో ఒక ప్రోగ్రామ్ దాని స్వంత అవుట్‌పుట్ ఎప్పుడు పూర్తవుతుందో తెలుసు, కానీ దాని సంభాషణ భాగస్వామి ఎప్పుడు పూర్తవుతుందో తెలియదు.


This closes communication in both directions on the socket.

ఇది సాకెట్‌పై రెండు దిశలలో కమ్యూనికేషన్‌ను మూసివేస్తుంది.


Since TCP supports streams of data, they might have already reminded you of normal files, which also support reading and writing as fundamental operations.

TCP డేటా స్ట్రీమ్‌లకు మద్దతు ఇస్తుంది కాబట్టి, అవి ఇప్పటికే సాధారణ ఫైల్‌లను గుర్తుకు తెచ్చి ఉండవచ్చు, ఇవి ప్రాథమిక కార్యకలాపాలుగా చదవడం మరియు రాయడానికి కూడా మద్దతు ఇస్తాయి.


Python does a very good job of keeping these concepts separate: file objects can read() and write(), sockets can send() and recv(), and no kind of object can do both.

ఈ భావనలను వేరుగా ఉంచడంలో పైథాన్ చాలా మంచి పని చేస్తుంది: ఫైల్ ఆబ్జెక్ట్‌లు read() మరియు write() చేయగలవు, సాకెట్‌లు send() మరియు recv() చేయగలవు మరియు ఏ రకమైన వస్తువు రెండూ చేయలేవు.


For this purpose, Python provides a makefile() method on every socket that returns a Python file object that is really calling recv() and send() behind the scenes:

ఈ ప్రయోజనం కోసం, పైథాన్ ప్రతి సాకెట్‌పై makefile() పద్ధతిని అందిస్తుంది, ఇది నిజంగా తెర వెనుక recv() మరియు send()ని పిలిచే పైథాన్ ఫైల్ ఆబ్జెక్ట్‌ను అందిస్తుంది:


The TCP-powered “stream” socket does whatever is necessary—including re-transmitting lost packets, reordering the ones that arrive out of sequence, and splitting very large data streams into optimally sized packets for your network in the first place—to support the transmission and reception of streams of data over the network between two sockets.

TCP-శక్తితో నడిచే “స్ట్రీమ్” సాకెట్ కోల్పోయిన ప్యాకెట్‌లను తిరిగి పంపడం, క్రమం తప్పకుండా వచ్చే వాటిని తిరిగి ఆర్డర్ చేయడం మరియు చాలా పెద్ద డేటా స్ట్రీమ్‌లను మీ నెట్‌వర్క్ కోసం సరైన పరిమాణంలో ప్యాకెట్‌లుగా విభజించడం వంటివి చేస్తుంది—రెండు సాకెట్‌ల మధ్య నెట్‌వర్క్ ద్వారా డేటా స్ట్రీమ్‌ల ప్రసారం మరియు స్వీకరణకు మద్దతు ఇవ్వడానికి.


As with UDP, port numbers are used by TCP to distinguish the many stream endpoints that might exist on a single machine.

UDP వలె, ఒకే యంత్రంలో ఉండగలిగే అనేక స్ట్రీమ్ ఎండ్‌పాయింట్‌లను వేరు చేయడానికి TCP ద్వారా పోర్ట్ నంబర్‌లు ఉపయోగించబడతాయి.


A program that wants to accept incoming TCP connections needs to bind() to a port, run listen() on the socket, and then go into a loop that runs accept() over and over to receive a new socket for each incoming connection with which it can talk to each particular client that connects.

ఇన్‌కమింగ్ TCP కనెక్షన్‌లను అంగీకరించాలనుకునే ప్రోగ్రామ్ పోర్ట్‌కు bind() చేయాలి, సాకెట్‌పై listen()ని అమలు చేయాలి, ఆపై ప్రతి ఇన్‌కమింగ్ కనెక్షన్ కోసం కొత్త సాకెట్‌ను స్వీకరించడానికి accept()ని పదేపదే అమలు చేసే లూప్‌లోకి వెళ్ళాలి, దానితో అది కనెక్ట్ అయ్యే ప్రతి నిర్దిష్ట క్లయింట్‌తో మాట్లాడగలదు.


Servers will usually want to set the SO_REUSEADDR option on the sockets they bind(), lest old connections still closing down on the same port from the last time the server was run prevent the operating system from allowing the binding.

సర్వర్లు సాధారణంగా వారు bind() చేసే సాకెట్‌లపై SO_REUSEADDR ఎంపికను సెట్ చేయాలనుకుంటారు, లేకపోతే సర్వర్ చివరిసారిగా రన్ అయినప్పుడు అదే పోర్ట్‌పై మూసివేయబడే పాత కనెక్షన్‌లు ఆపరేటింగ్ సిస్టమ్ బంధించడానికి అనుమతించకుండా నిరోధిస్తాయి.


Data is actually sent and received with send() and recv().

డేటాను వాస్తవానికి send() మరియు recv()తో పంపబడుతుంది మరియు స్వీకరించబడుతుంది.


The shutdown() socket method can be used to produce end-of-file in one direction on a socket (all sockets are bidirectional by nature) while leaving the other direction open.

shutdown() సాకెట్ పద్ధతిని సాకెట్‌పై ఒక దిశలో ఫైల్ ముగింపును ఉత్పత్తి చేయడానికి ఉపయోగించవచ్చు (అన్ని సాకెట్‌లు స్వభావరీత్యా ద్విదిశాత్మకమైనవి), అయితే ఇతర దిశను తెరిచి ఉంచుతుంది.


Deadlock can occur if two peers are written such that the socket fills with more and more data that never gets read.

రెండు పీర్‌లు వ్రాయబడితే, సాకెట్ ఎప్పటికీ చదవబడని ఎక్కువ డేటాతో నిండిపోతే డెడ్‌లాక్ సంభవించవచ్చు.


If you want to pass a socket to a Python routine that knows how to read to or write from a normal file object, the makefile() socket method will give you a Python object that calls recv() and send() behind the scenes when the caller needs to read and write.

మీరు సాధారణ ఫైల్ ఆబ్జెక్ట్ నుండి ఎలా చదవాలో లేదా ఎలా రాయాలో తెలిసిన పైథాన్ రొటీన్‌కు సాకెట్‌ను పంపాలనుకుంటే, makefile() సాకెట్ పద్ధతి మీకు పైథాన్ ఆబ్జెక్ట్‌ను అందిస్తుంది, ఇది కాలర్ చదవడానికి మరియు వ్రాయడానికి అవసరమైనప్పుడు తెర వెనుక recv() మరియు send()ని పిలుస్తుంది.


In general, an FQDN may be used to identify a host from anywhere else on the Internet.

సాధారణంగా, ఇంటర్నెట్‌లో మరెక్కడి నుండైనా హోస్ట్‌ను గుర్తించడానికి FQDNని ఉపయోగించవచ్చు.


While you might have been able to pick up some scattered facts about socket names from the last few chapters—like the fact that the first item can be either a hostname or a dotted IP address—it is time for us to approach the whole subject in more depth.

చివరి కొన్ని అధ్యాయాల నుండి సాకెట్ పేర్ల గురించి కొన్ని విషయాలు మీరు తెలుసుకుని ఉండవచ్చు—మొదటి అంశం హోస్ట్‌పేరు లేదా డాటెడ్ IP చిరునామా కావచ్చు—మనం మొత్తం విషయాన్ని మరింత లోతుగా పరిశీలించాల్సిన సమయం ఆసన్నమైంది.


For your reference, here are all of the major socket methods that demand of you some sort of socket name as an argument:

మీ సూచన కోసం, ఇక్కడ కొన్ని సాకెట్ పేరును వాదనగా కోరే ప్రధాన సాకెట్ పద్ధతులు ఉన్నాయి:


In order, here is the full list of values that had to be chosen, and you will see that there are five in all.

క్రమంలో, ఎంచుకోవలసిన విలువల పూర్తి జాబితా ఇక్కడ ఉంది మరియు మొత్తం ఐదు ఉన్నాయని మీరు చూస్తారు.


For example, an HTTP request often consists of headers, a blank line, and then however many further bytes of data were specified in the Content-length header.

ఉదాహరణకు, HTTP అభ్యర్థన తరచుగా హెడర్‌లు, ఖాళీ లైన్ మరియు కంటెంట్-లెంగ్త్ హెడర్‌లో పేర్కొన్న డేటా యొక్క మరిన్ని బైట్‌లను కలిగి ఉంటుంది.


You would not know how many times to keep running recv() until you had at least received the headers and then parsed them to find out the content length!

మీరు కనీసం హెడర్‌లను స్వీకరించే వరకు మరియు కంటెంట్ పొడవును తెలుసుకోవడానికి వాటిని విశ్లేషించే వరకు recv()ని ఎన్నిసార్లు అమలు చేయాలో మీకు తెలియదు!


Recall from our foregoing discussion that there are two very different kinds of stream sockets: listening sockets, with which servers make a port available for incoming connections, and connected sockets, which represent the conversation that a server is having with a particular client.

మునుపటి చర్చ నుండి గుర్తుకు తెచ్చుకోండి, రెండు రకాల స్ట్రీమ్ సాకెట్‌లు ఉన్నాయి: వినడానికి సాకెట్‌లు, దీనితో సర్వర్లు ఇన్‌కమింగ్ కనెక్షన్‌ల కోసం పోర్ట్‌ను అందుబాటులో ఉంచుతాయి మరియు కనెక్ట్ చేయబడిన సాకెట్‌లు, ఇవి ఒక నిర్దిష్ట క్లయింట్‌తో సర్వర్ చేస్తున్న సంభాషణను సూచిస్తాయి.


In Listing 3–1, you can see how this distinction is carried through in actual server code.

లిస్టింగ్ 3–1లో, ఈ వ్యత్యాసం వాస్తవ సర్వర్ కోడ్‌లో ఎలా కొనసాగుతుందో మీరు చూడవచ్చు.


The link, which might strike you as odd at first, is that a listening socket actually produces new connected sockets as the return value that you get by listening!

మొదట విచిత్రంగా అనిపించే లింక్ ఏమిటంటే, వినడానికి సాకెట్ వాస్తవానికి వినడం ద్వారా మీరు పొందే రిటర్న్ విలువగా కొత్త కనెక్ట్ చేయబడిన సాకెట్‌లను ఉత్పత్తి చేస్తుంది!


First, the server runs bind() to claim a particular port.

ముందుగా, సర్వర్ నిర్దిష్ట పోర్ట్‌ను క్లెయిమ్ చేయడానికి bind()ని అమలు చేస్తుంది.


Note that this does not yet decide whether the socket will be a client or server socket—that is, whether it will be actively making a connection or passively waiting to receive incoming connections.

సాకెట్ క్లయింట్ లేదా సర్వర్ సాకెట్ అవుతుందా అని ఇది ఇంకా నిర్ణయించలేదు—అంటే, ఇది చురుకుగా కనెక్షన్ చేస్తుందా లేదా ఇన్‌కమింగ్ కనెక్షన్‌లను స్వీకరించడానికి నిష్క్రియంగా వేచి ఉంటుందా.


Clients can use this call if, for some reason, they want to reach out to a server from a particular port on their machine rather than simply accepting whatever ephemeral port number they would otherwise be assigned.

కొన్ని కారణాల వల్ల, క్లయింట్‌లు తమ మెషీన్‌లోని నిర్దిష్ట పోర్ట్ నుండి సర్వర్‌ను సంప్రదించాలనుకుంటే, వారు కేటాయించబడే తాత్కాలిక పోర్ట్ నంబర్‌ను స్వీకరించడానికి బదులుగా ఈ కాల్‌ని ఉపయోగించవచ్చు.


The real moment of decision comes with the next method call, when the server announces that it wants to use the socket to listen().

నిజమైన నిర్ణయం తదుపరి పద్ధతి కాల్‌తో వస్తుంది, సర్వర్ సాకెట్‌ను వినడానికి ఉపయోగించాలనుకుంటున్నట్లు ప్రకటించినప్పుడు.


Running this on a TCP socket utterly transforms its character: after listen() has been called, the socket is irrevocably changed and can never, from this point on, be used to send or receive data.

దీన్ని TCP సాకెట్‌లో అమలు చేయడం దాని స్వభావాన్ని పూర్తిగా మారుస్తుంది: listen()ని పిలిచిన తర్వాత, సాకెట్ కోలుకోలేని విధంగా మార్చబడుతుంది మరియు ఈ సమయంలో డేటాను పంపడానికి లేదా స్వీకరించడానికి ఎప్పటికీ ఉపయోగించబడదు.


Instead, the socket can now be used only to receive incoming connections through its accept() method—a method that we have not seen yet in this book, because its purpose is solely to support listening TCP sockets—and each of these calls waits for a new client to connect and then returns an entirely new socket that governs the new conversation that has just started with them!

బదులుగా, సాకెట్‌ను ఇప్పుడు దాని accept() పద్ధతి ద్వారా ఇన్‌కమింగ్ కనెక్షన్‌లను స్వీకరించడానికి మాత్రమే ఉపయోగించవచ్చు—ఈ పుస్తకంలో మనం ఇంకా చూడని ఒక పద్ధతి, ఎందుకంటే దాని ఉద్దేశ్యం వినడానికి TCP సాకెట్‌లకు మాత్రమే మద్దతు ఇవ్వడం—మరియు ఈ కాల్‌లలో ప్రతి ఒక్కటి కొత్త క్లయింట్ కనెక్ట్ అవ్వడానికి వేచి ఉంటుంది మరియు ఆపై వారితో ఇప్పుడే ప్రారంభమైన కొత్త సంభాషణను నియంత్రించే పూర్తిగా కొత్త సాకెట్‌ను అందిస్తుంది!


As you can see from the code, getsockname() works fine against both listening and connected sockets, and in both cases lets you find out what local TCP port the socket is occupying.

మీరు కోడ్ నుండి చూడగలిగినట్లుగా, getsockname() వినడానికి మరియు కనెక్ట్ చేయబడిన సాకెట్‌లకు వ్యతిరేకంగా బాగా పనిచేస్తుంది మరియు రెండు సందర్భాల్లోనూ సాకెట్ ఏ స్థానిక TCP పోర్ట్‌ను ఆక్రమిస్తుందో తెలుసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది.


To learn the address of the client to which a connected socket is connected, you can at any time run the getpeername() method, or you can store the socket name that is returned as the second return value from accept().

కనెక్ట్ చేయబడిన సాకెట్ కనెక్ట్ చేయబడిన క్లయింట్ యొక్క చిరునామాను తెలుసుకోవడానికి, మీరు ఎప్పుడైనా getpeername() పద్ధతిని అమలు చేయవచ్చు లేదా accept() నుండి రెండవ రిటర్న్ విలువగా తిరిగి వచ్చే సాకెట్ పేరును నిల్వ చేయవచ్చు.


When we run this server, we see that both values give us the same address: $ python tcp_sixteen.py server Listening at ('127.0.0.1', 1060) We have accepted a connection from ('127.0.0.1', 58185) Socket connects ('127.0.0.1', 1060) and ('127.0.0.1', 58185) The incoming sixteen-octet message says 'Hi there, server' Reply sent, socket closed Listening at ('127.0.0.1', 1060)

మేము ఈ సర్వర్‌ను అమలు చేసినప్పుడు, రెండు విలువలు మాకు ఒకే చిరునామాను ఇస్తున్నాయని మేము చూస్తాము: $ python tcp_sixteen.py server Listening at ('127.0.0.1', 1060) We have accepted a connection from ('127.0.0.1', 58185) Socket connects ('127.0.0.1', 1060) and ('127.0.0.1', 58185) The incoming sixteen-octet message says 'Hi there, server' Reply sent, socket closed Listening at ('127.0.0.1', 1060)


The foregoing example output is produced by having the client make one connection to the server, like this: $ python tcp_sixteen.py client Client has been assigned socket name ('127.0.0.1', 58185) The server said 'Farewell, client'

మునుపటి ఉదాహరణ అవుట్‌పుట్ క్లయింట్ సర్వర్‌కు ఒక కనెక్షన్ చేసినప్పుడు ఉత్పత్తి అవుతుంది, ఈ విధంగా: $ python tcp_sixteen.py client Client has been assigned socket name ('127.0.0.1', 58185) The server said 'Farewell, client'


You can see from the rest of the server code that, once a connected socket has been returned by accept(), it works exactly like a client socket with no further asymmetries evident in their pattern of communication.

మిగిలిన సర్వర్ కోడ్ నుండి మీరు చూడగలిగినట్లుగా, accept() ద్వారా కనెక్ట్ చేయబడిన సాకెట్ తిరిగి వచ్చిన తర్వాత, ఇది కమ్యూనికేషన్ నమూనాలో మరింత అసమానతలు లేకుండా క్లయింట్ సాకెట్ లాగా ఖచ్చితంగా పనిచేస్తుంది.


The recv() call returns data as it becomes available, and sendall() is the best way to send a new string of data when you want to make sure that it all gets transmitted.

recv() కాల్ అందుబాటులోకి వచ్చినప్పుడు డేటాను అందిస్తుంది మరియు మీరు అంతా ప్రసారం చేయబడిందని నిర్ధారించుకోవాలనుకున్నప్పుడు కొత్త డేటా స్ట్రింగ్‌ను పంపడానికి sendall() ఉత్తమ మార్గం.


You will note that an integer argument was provided to listen() when it was called on the server socket.

సర్వర్ సాకెట్‌లో పిలిచినప్పుడు listen()కి పూర్ణాంక వాదన అందించబడిందని మీరు గమనించాలి.


This number indicates how many waiting connections, which have not yet had sockets created for them by accept() calls, should be allowed to stack up before the operating system starts turning new connections away by returning connection errors.

ఈ సంఖ్య ఎన్ని నిరీక్షణ కనెక్షన్‌లను సూచిస్తుంది, ఇవి accept() కాల్‌ల ద్వారా వాటి కోసం ఇంకా సాకెట్‌లను సృష్టించలేదు, ఆపరేటింగ్ సిస్టమ్ కనెక్షన్ లోపాలను తిరిగి ఇవ్వడం ద్వారా కొత్త కనెక్షన్‌లను తిరస్కరించడం ప్రారంభించే ముందు పేరుకుపోవడానికి అనుమతించాలి.


We are using the very small value 1 here in our examples because we support only one example client connecting at a time; but we will consider larger values for this call when we talk about network server design in Chapter 7.

మేము ఇక్కడ మా ఉదాహరణలలో చాలా చిన్న విలువ 1ని ఉపయోగిస్తున్నాము, ఎందుకంటే మేము ఒకే ఉదాహరణ క్లయింట్ ఒకేసారి కనెక్ట్ అవ్వడానికి మద్దతు ఇస్తున్నాము; కానీ మనం అధ్యాయం 7లో నెట్‌వర్క్ సర్వర్ డిజైన్ గురించి మాట్లాడేటప్పుడు ఈ కాల్ కోసం పెద్ద విలువలను పరిగణనలోకి తీసుకుంటాము.


You can see that supplying the IPv4 address for the localhost locks you down to receiving connections only over IPv4.

localhost కోసం IPv4 చిరునామాను అందించడం వలన మీరు IPv4 ద్వారా మాత్రమే కనెక్షన్లను స్వీకరించడానికి పరిమితం చేయబడతారు.


One question that you might already be asking at this point, by the way, is what on earth you are supposed to do when you assert that you want to supply a basic service and getaddrinfo() goes and gives you several addresses to use.

మీరు ప్రాథమిక సేవను అందించాలని పేర్కొన్నప్పుడు మరియు getaddrinfo() ఉపయోగించడానికి అనేక చిరునామాలను ఇచ్చినప్పుడు మీరు ఏమి చేయాలో ఈ సమయంలో మీరు అడగవచ్చు.


In Chapter 7, we will tackle the techniques that you can use if you are writing server code and want to have several sockets going at once.

అధ్యాయం 7లో, మీరు సర్వర్ కోడ్‌ను వ్రాస్తుంటే మరియు ఒకేసారి అనేక సాకెట్‌లను కలిగి ఉండాలనుకుంటే మీరు ఉపయోగించగల పద్ధతులను మేము చర్చిస్తాము.


The usual use of getaddrinfo() in all other cases—which, basically, is when you are preparing to connect() or sendto()—is to specify the AI_ADDRCONFIG flag, which filters out any addresses that are impossible for your computer to reach.

మిగిలిన అన్ని సందర్భాల్లో getaddrinfo() యొక్క సాధారణ ఉపయోగం—ప్రాథమికంగా, మీరు కనెక్ట్() లేదా sendto() కోసం సిద్ధమవుతున్నప్పుడు—AI_ADDRCONFIG ఫ్లాగ్‌ను పేర్కొనడం, ఇది మీ కంప్యూటర్ చేరుకోలేని ఏ చిరునామాలను అయినా ఫిల్టర్ చేస్తుంది.


For example, an organization might have both an IPv4 and an IPv6 range of IP addresses; but if your particular host supports only IPv4, then you will want the results filtered to include only addresses in that family.

ఉదాహరణకు, ఒక సంస్థ IPv4 మరియు IPv6 IP చిరునామాల శ్రేణిని కలిగి ఉండవచ్చు; కానీ మీ నిర్దిష్ట హోస్ట్ IPv4ని మాత్రమే సపోర్ట్ చేస్తే, మీరు ఆ కుటుంబంలోని చిరునామాలను మాత్రమే చేర్చడానికి ఫలితాలను ఫిల్టర్ చేయాలనుకుంటున్నారు.


In case the local machine has only an IPv6 network interface but the service you are connecting to is supporting only IPv4, the AI_V4MAPPED will return you those IPv4 addresses re-encoded as IPv6 addresses that you can actually use.

స్థానిక మెషీన్‌లో IPv6 నెట్‌వర్క్ ఇంటర్‌ఫేస్ మాత్రమే ఉన్న సందర్భంలో, మీరు కనెక్ట్ అవుతున్న సేవ IPv4ని మాత్రమే సపోర్ట్ చేస్తే, AI_V4MAPPED మీకు ఆ IPv4 చిరునామాలను మీరు వాస్తవానికి ఉపయోగించగల IPv6 చిరునామాలుగా మారుస్తుంది.


And we have gotten exactly what we wanted: every way to connect to a host named ftp.kernel.org through a TCP connection to its FTP port.

మనం కోరుకున్నది ఖచ్చితంగా పొందాము: ftp.kernel.org అనే హోస్ట్‌కి దాని FTP పోర్ట్‌కి TCP కనెక్షన్ ద్వారా కనెక్ట్ అవ్వడానికి ప్రతి మార్గం.


Note that several IP addresses were returned because this service, to spread load, is located at several different machines on the Internet.

లోడ్‌ను విస్తరించడానికి, ఈ సేవ ఇంటర్నెట్‌లో అనేక విభిన్న మెషీన్‌లలో ఉన్నందున, అనేక IP చిరునామాలు తిరిగి ఇవ్వబడ్డాయి.


You should generally always use the first address returned, and if a connection fails, then try the remaining ones, because there is intelligence built into the name-resolution system to properly randomize the order in which you receive them.

మీరు సాధారణంగా ఎల్లప్పుడూ తిరిగి వచ్చిన మొదటి చిరునామాను ఉపయోగించాలి మరియు కనెక్షన్ విఫలమైతే, మిగిలిన వాటిని ప్రయత్నించండి, ఎందుకంటే మీరు వాటిని స్వీకరించే క్రమాన్ని సరిగ్గా యాదృచ్ఛికంగా చేయడానికి పేరు-రిజల్యూషన్ సిస్టమ్‌లో తెలివితేటలు నిర్మించబడ్డాయి.


Here is another query, which describes how I can connect from my laptop to the HTTP interface of the IANA that assigns port numbers in the first place:

మొదట పోర్ట్ నంబర్‌లను కేటాయించే IANA యొక్క HTTP ఇంటర్‌ఫేస్‌కి నా ల్యాప్‌టాప్ నుండి నేను ఎలా కనెక్ట్ అవ్వగలనో వివరించే మరొక ప్రశ్న ఇక్కడ ఉంది:


The IANA web site is actually a good one for demonstrating the utility of the AI_ADDRCONFIG flag, because—like any other good Internet standards organization—their web site already supports IPv6.

IANA వెబ్‌సైట్ వాస్తవానికి AI_ADDRCONFIG ఫ్లాగ్ యొక్క యుటిలిటీని ప్రదర్శించడానికి మంచిది, ఎందుకంటే—మరేదైనా మంచి ఇంటర్నెట్ ప్రమాణాల సంస్థలాగే—వారి వెబ్‌సైట్ ఇప్పటికే IPv6కి మద్దతు ఇస్తుంది.


This can be useful if you are not going to try to use the addresses yourself, but if you are providing some sort of directory information to other hosts or programs.

మీరు చిరునామాలను ఉపయోగించడానికి ప్రయత్నించకపోతే ఇది ఉపయోగకరంగా ఉంటుంది, కానీ మీరు ఇతర హోస్ట్‌లు లేదా ప్రోగ్రామ్‌లకు ఏదైనా డైరెక్టరీ సమాచారాన్ని అందిస్తుంటే.


One last circumstance that you will commonly encounter is where you either are making a new connection, or maybe have just received a connection to one of your own sockets, and you want an attractive hostname to display to the user or record in a log file.

మీరు సాధారణంగా ఎదుర్కొనే చివరి పరిస్థితి ఏమిటంటే, మీరు కొత్త కనెక్షన్‌ను ఏర్పరుస్తున్నప్పుడు లేదా మీ స్వంత సాకెట్‌లలో ఒకదానికి కనెక్షన్‌ను స్వీకరించినప్పుడు, మీరు వినియోగదారుకు ప్రదర్శించడానికి లేదా లాగ్ ఫైల్‌లో రికార్డ్ చేయడానికి ఆకర్షణీయమైన హోస్ట్ పేరును కోరుకుంటారు.


This is slightly dangerous because a hostname lookup can take quite a bit of time, even on the modern Internet, and might return a hostname that no longer works by the time you go and check your logs—so for log files, try to record both the hostname and raw IP address!

హోస్ట్ పేరును చూడటానికి చాలా సమయం పట్టవచ్చు కాబట్టి ఇది కొంచెం ప్రమాదకరమైనది, ఆధునిక ఇంటర్నెట్‌లో కూడా, మరియు మీరు మీ లాగ్‌లను తనిఖీ చేయడానికి వెళ్ళే సమయానికి ఇక పని చేయని హోస్ట్ పేరును తిరిగి ఇవ్వవచ్చు—కాబట్టి లాగ్ ఫైల్‌ల కోసం, హోస్ట్ పేరు మరియు ముడి IP చిరునామా రెండింటినీ రికార్డ్ చేయడానికి ప్రయత్నించండి!


You can also supply getaddrinfo() with the attributes of a socket that is already connected to a remote peer, and get a canonical name in return:

మీరు ఇప్పటికే రిమోట్ పీర్‌కి కనెక్ట్ చేయబడిన సాకెట్ యొక్క లక్షణాలతో getaddrinfo()ని కూడా అందించవచ్చు మరియు బదులుగా ప్రామాణిక పేరును పొందవచ్చు:


Again, this will work only if the owner of the IP address happens to have a name defined for it (and, obviously, it requires the hostname lookup to succeed).

మళ్ళీ, IP చిరునామా యజమానికి దాని కోసం పేరు నిర్వచించబడితే మాత్రమే ఇది పని చేస్తుంది (మరియు, స్పష్టంగా, ఇది హోస్ట్ పేరును చూడటం విజయవంతం కావాలి).


The flags available vary somewhat by operating system, and you should always consult your own computer's documentation (not to mention its configuration!) if you are confused about a value that it chooses to return.

అందుబాటులో ఉన్న ఫ్లాగ్‌లు ఆపరేటింగ్ సిస్టమ్‌ను బట్టి కొంతవరకు మారుతూ ఉంటాయి మరియు అది తిరిగి ఇవ్వడానికి ఎంచుకున్న విలువ గురించి మీకు అయోమయంగా ఉంటే మీరు ఎల్లప్పుడూ మీ స్వంత కంప్యూటర్ డాక్యుమెంటేషన్‌ను సంప్రదించాలి (దాని కాన్ఫిగరేషన్‌ను చెప్పనవసరం లేదు!).


AI_ALL: We have already discussed that the AI_V4MAPPED option will save you in the situation where you are on a purely IPv6-connected host, but the host to which you want to connect advertises only IPv4 addresses: it resolves this problem by “mapping” the IPv4 addresses to their IPv6 equivalent.

AI_ALL: మీరు పూర్తిగా IPv6-కనెక్ట్ చేయబడిన హోస్ట్‌లో ఉన్న పరిస్థితిలో AI_V4MAPPED ఎంపిక మిమ్మల్ని ఎలా కాపాడుతుందో మేము ఇప్పటికే చర్చించాము, అయితే మీరు కనెక్ట్ అవ్వాలనుకుంటున్న హోస్ట్ IPv4 చిరునామాలను మాత్రమే ప్రకటిస్తుంది: ఇది IPv4 చిరునామాలను వాటి IPv6 సమానానికి “మ్యాపింగ్” చేయడం ద్వారా ఈ సమస్యను పరిష్కరిస్తుంది.


AI_NUMERICHOST: This turns off any attempt to interpret the hostname parameter (the first parameter to getaddrinfo()) as a textual hostname like cern.ch, and only tries to interpret the hostname string as a literal IPv4 or IPv6 hostname like 74.207.234.78 or fe80::fcfd:4aff:fecf:ea4e.

AI_NUMERICHOST: ఇది హోస్ట్ పేరు పరామితిని (getaddrinfo()కి మొదటి పరామితి) cern.ch వంటి టెక్స్ట్‌తో కూడిన హోస్ట్ పేరుగా అర్థం చేసుకోవడానికి చేసే ప్రయత్నాన్ని ఆపివేస్తుంది మరియు హోస్ట్ పేరు స్ట్రింగ్‌ను 74.207.234.78 లేదా fe80::fcfd:4aff:fecf:ea4e వంటి అక్షర IPv4 లేదా IPv6 హోస్ట్ పేరుగా అర్థం చేసుకోవడానికి మాత్రమే ప్రయత్నిస్తుంది.


AI_NUMERICSERV: This turns off symbolic port names like www and insists that port numbers like 80 be used instead.

AI_NUMERICSERV: ఇది www వంటి సాంకేతిక పోర్ట్ పేర్లను ఆపివేస్తుంది మరియు బదులుగా 80 వంటి పోర్ట్ నంబర్‌లను ఉపయోగించాలని పట్టుబడుతుంది.


Each hex digit corresponds to four bits, so each pair of hex digits represents a byte of data.

ప్రతి హెక్స్ అంకె నాలుగు బిట్‌లకు అనుగుణంగా ఉంటుంది, కాబట్టి ప్రతి హెక్స్ అంకెల జత డేటా యొక్క ఒక బైట్‌ను సూచిస్తుంది.


Some computers are “big-endian” and put the most significant byte first, just like we do when writing decimal digits; others are “little-endian” and put the least significant byte first.

కొన్ని కంప్యూటర్లు “బిగ్-ఎండియన్” మరియు అత్యంత ముఖ్యమైన బైట్‌ను మొదట ఉంచుతాయి, మనం దశాంశ అంకెలను రాసినప్పుడు చేసినట్లుగానే; మరికొన్ని “లిటిల్-ఎండియన్” మరియు అతి తక్కువ ముఖ్యమైన బైట్‌ను మొదట ఉంచుతాయి.


Python makes it very easy to see the difference between the two endiannesses.

రెండు ఎండియన్‌ల మధ్య వ్యత్యాసాన్ని చూడటం పైథాన్‌తో చాలా సులభం.


Simply use the struct module, which provides a variety of operations for converting data to and from popular binary formats.

డేటాను ప్రముఖ బైనరీ ఫార్మాట్‌లకు మరియు వాటి నుండి మార్చడానికి అనేక కార్యకలాపాలను అందించే struct మాడ్యూల్‌ను ఉపయోగించండి.


Here is the number 4253 represented first in a little-endian format and then in a big-endian order:

ఇక్కడ 4253 సంఖ్య మొదట లిటిల్-ఎండియన్ ఆకృతిలో మరియు తరువాత బిగ్-ఎండియన్ క్రమంలో సూచించబడింది:


You can think of the struct codes for these two orders as little arrows pointing toward the least significant end of a string of bytes.

ఈ రెండు ఆర్డర్‌ల కోసం struct కోడ్‌లను మీరు చిన్న బాణాలుగా భావించవచ్చు, ఇవి బైట్‌ల స్ట్రింగ్ యొక్క అతి తక్కువ ముఖ్యమైన ముగింపు వైపు చూపిస్తాయి.


Select network byte order with the '!' prefix if the data form at is up to you.

డేటా ఫార్మాట్ మీ ఇష్టం అయితే '!' ఉపసర్గతో నెట్‌వర్క్ బైట్ ఆర్డర్‌ను ఎంచుకోండి.


If someone else has designed the protocol and specified little-endian, then you will have to use '<' instead.

మరొకరు ప్రోటోకాల్‌ను రూపొందించి, లిటిల్-ఎండియన్‌ను పేర్కొంటే, మీరు '<' ని ఉపయోగించాలి.


Always test struct to see how it lays out your data compared to the specification for the protocol you are speaking.

మీరు మాట్లాడుతున్న ప్రోటోకాల్ కోసం స్పెసిఫికేషన్‌తో పోలిస్తే మీ డేటాను అది ఎలా ఉంచుతుందో చూడటానికి ఎల్లప్పుడూ struct ని పరీక్షించండి.


I suggest that you ignore these awkward functions, and use the struct module instead; it is more flexible, more general, and produces more readable code.

ఈ ఇబ్బందికరమైన ఫంక్షన్లను విస్మరించమని నేను సూచిస్తున్నాను మరియు బదులుగా struct మాడ్యూల్‌ను ఉపయోగించండి; ఇది మరింత సౌకర్యవంతంగా, మరింత సాధారణంగా ఉంటుంది మరియు మరింత చదవగలిగే కోడ్‌ను ఉత్పత్తి చేస్తుంది.


If you are using UDP datagrams for communication, then the protocol itself takes the trouble to deliver your data in discrete and identifiable chunks.

మీరు కమ్యూనికేషన్ కోసం UDP డేటాగ్రామ్‌లను ఉపయోగిస్తుంటే, ప్రోటోకాల్ మీ డేటాను ప్రత్యేకమైన మరియు గుర్తించదగిన ముక్కలుగా అందించడానికి శ్రద్ధ తీసుకుంటుంది.


But if you have made the far more common option of using a TCP stream for communication, then you will face the issue of framing.

కానీ మీరు కమ్యూనికేషన్ కోసం TCP స్ట్రీమ్‌ను ఉపయోగించడం యొక్క సాధారణ ఎంపికను ఎంచుకుంటే, మీరు ఫ్రేమింగ్ సమస్యను ఎదుర్కొంటారు.


Since the data you supply to sendall() might be broken up into several packets, the program that receives your message might have to make several recv() calls before your whole message has been read.

మీరు sendall()కి అందించే డేటా అనేక ప్యాకెట్‌లుగా విభజించబడవచ్చు కాబట్టి, మీ సందేశాన్ని స్వీకరించే ప్రోగ్రామ్ మీ మొత్తం సందేశం చదవడానికి ముందు అనేక recv() కాల్‌లు చేయవలసి ఉంటుంది.


The issue of framing asks the question: when is it safe for the receiver to finally stop calling recv() and respond to your message?

ఫ్రేమింగ్ సమస్య ఈ ప్రశ్నను లేవనెత్తుతుంది: రిసీవర్ చివరకు recv()ని కాల్ చేయడం ఆపి, మీ సందేశానికి ప్రతిస్పందించడం ఎప్పుడు సురక్షితం?


First, there is a pattern that can be used by extremely simple network protocols that involve only the delivery of data.

ముందుగా, డేటాను అందించడం మాత్రమే కలిగి ఉన్న అత్యంత సాధారణ నెట్‌వర్క్ ప్రోటోకాల్‌ల ద్వారా ఉపయోగించగల నమూనా ఉంది.


In this case, the sender can loop until all of the outgoing data has been passed to sendall() and then close() the socket.

ఈ సందర్భంలో, పంపేవారు మొత్తం అవుట్‌గోయింగ్ డేటా sendall()కి పంపబడే వరకు లూప్ చేయవచ్చు మరియు తరువాత సాకెట్‌ను close() చేయవచ్చు.


The receiver need only call recv() repeatedly until the call finally returns an empty string, indicating that the sender has finally closed the socket.

పంపేవారు చివరకు సాకెట్‌ను మూసివేశారని సూచిస్తూ, కాల్ చివరకు ఖాళీ స్ట్రింగ్‌ను తిరిగి ఇచ్చే వరకు రిసీవర్ పదేపదే recv()ని మాత్రమే కాల్ చేయాలి.


Note the nicety that, since this socket is not intended to receive any data, the client and server both go ahead and shut down communication in the other direction.

ఈ సాకెట్ ఎలాంటి డేటాను స్వీకరించడానికి ఉద్దేశించబడనందున, క్లయింట్ మరియు సర్వర్ రెండూ ఇతర దిశలో కమ్యూనికేషన్‌ను మూసివేస్తాయని గమనించండి.


A second pattern is a variant on the first: streaming in both directions.

రెండవ నమూనా మొదటి దాని యొక్క ఒక వైవిధ్యం: రెండు దిశలలో స్ట్రీమింగ్.


A third pattern, which we have already seen, is to use fixed-length messages.

మనం ఇప్పటికే చూసిన మూడవ నమూనా, స్థిర-పొడవు సందేశాలను ఉపయోగించడం.


Imagine that these 28 bytes arrive at their destination in 8-byte packets.

ఈ 28 బైట్‌లు 8-బైట్ ప్యాకెట్‌లలో గమ్యస్థానానికి చేరుకుంటాయని ఊహించండి.


After processing the first packet, we will find the decompression object's unused_data slot still empty.

మొదటి ప్యాకెట్‌ను ప్రాసెస్ చేసిన తర్వాత, డీకంప్రెషన్ ఆబ్జెక్ట్ యొక్క unused_data స్లాట్ ఇంకా ఖాళీగా ఉందని మేము కనుగొంటాము.


If another stream of compressed data is coming, then we have to provide everything past the '.'

మరొక కంప్రెస్ చేయబడిన డేటా స్ట్రీమ్ వస్తుంటే, మనం '.' తర్వాత ఉన్న ప్రతిదాన్ని అందించాలి.


Again, most protocol designers make compression optional and simply do their own framing.

మళ్ళీ, చాలా ప్రోటోకాల్ డిజైనర్లు కంప్రెషన్‌ను ఐచ్ఛికంగా చేస్తారు మరియు వారి స్వంత ఫ్రేమింగ్‌ను చేస్తారు.


So when we illustrated socket timeouts in Listing 2-2, we were careful to catch the exception socket.timeout.

కాబట్టి మేము జాబితా 2-2లో సాకెట్ టైమ్‌అవుట్‌లను వివరించినప్పుడు, మేము socket.timeout మినహాయింపును జాగ్రత్తగా పట్టుకున్నాము.


This exception is raised when getaddrinfo() cannot find a name or service that you ask about.

మీరు అడిగిన పేరు లేదా సేవను getaddrinfo() కనుగొనలేనప్పుడు ఈ మినహాయింపు ఏర్పడుతుంది.


This is the workhorse of the socket module, and will be raised for nearly every failure that can happen at any stage in a network transmission.

ఇది సాకెట్ మాడ్యూల్ యొక్క వర్క్‌హార్స్, మరియు నెట్‌వర్క్ ప్రసారంలో ఏ దశలోనైనా జరిగే దాదాపు ప్రతి వైఫల్యానికి ఇది ఏర్పడుతుంది.


This exception is raised only if you, or a library that you are using, decides to set a timeout on a socket.

మీరు లేదా మీరు ఉపయోగిస్తున్న లైబ్రరీ సాకెట్‌పై టైమ్‌అవుట్‌ను సెట్ చేయాలని నిర్ణయించుకుంటే మాత్రమే ఈ మినహాయింపు ఏర్పడుతుంది.


A big question when you are using higher-level socket-based protocols from Python is whether they allow raw socket errors to hit your own code.

మీరు పైథాన్ నుండి అధిక-స్థాయి సాకెట్-ఆధారిత ప్రోటోకాల్‌లను ఉపయోగిస్తున్నప్పుడు ఒక పెద్ద ప్రశ్న ఏమిటంటే, అవి మీ స్వంత కోడ్‌ను తాకడానికి ముడి సాకెట్ లోపాలను అనుమతిస్తాయా లేదా.


Consult documentation carefully if you are in doubt about the approach taken by a particular library.

ఒక నిర్దిష్ట లైబ్రరీ తీసుకున్న విధానం గురించి మీకు సందేహం ఉంటే, డాక్యుమెంటేషన్‌ను జాగ్రత్తగా సంప్రదించండి.


For the major packages that we cover in the subsequent chapters of this book, I have tried to provide insets that list the possible exceptions.

ఈ పుస్తకం యొక్క తదుపరి అధ్యాయాలలో మేము కవర్ చేసే ప్రధాన ప్యాకేజీల కోసం, సాధ్యమయ్యే మినహాయింపులను జాబితా చేసే ఇన్‌సెట్‌లను అందించడానికి నేను ప్రయత్నించాను.


When writing a network program, how should you handle all of the errors that can occur?

నెట్‌వర్క్ ప్రోగ్రామ్‌ను వ్రాసేటప్పుడు, మీరు సంభవించే అన్ని లోపాలను ఎలా నిర్వహించాలి?


The first is not to handle exceptions at all.

మొదటిది ఏమిటంటే మినహాయింపులను అస్సలు నిర్వహించకూడదు.


If you are writing a library of calls to be used by other programmers, then this first approach is usually preferable.

మీరు ఇతర ప్రోగ్రామర్‌లు ఉపయోగించాల్సిన కాల్‌ల లైబ్రరీని వ్రాస్తుంటే, అప్పుడు ఈ మొదటి విధానం సాధారణంగా ఉత్తమం.


But if you are indeed writing a library, then there is a second approach to consider: wrapping the network errors in an exception of your own.

కానీ మీరు నిజంగా ఒక లైబ్రరీని వ్రాస్తుంటే, పరిగణించవలసిన రెండవ విధానం ఉంది: నెట్‌వర్క్ లోపాలను మీ స్వంత మినహాయింపులో చుట్టడం.


If you offer a netcopy() method that copies a file from one remote machine to another, for example, a socket.error does not help the caller know whether the error was with the connection to the source machine.

మీరు ఒక ఫైల్‌ను ఒక రిమోట్ మెషిన్ నుండి మరొకదానికి కాపీ చేసే netcopy() పద్ధతిని అందిస్తే, ఉదాహరణకు, సోర్స్ మెషిన్‌కు కనెక్షన్‌తో లోపం ఉందో లేదో తెలుసుకోవడానికి socket.error సహాయపడదు.


A third approach to exceptions is to wrap a try...except clause around every single network call that you ever make, and print out a pithy error message in its place.

మినహాయింపులకు మూడవ విధానం ఏమిటంటే, మీరు ఎప్పుడైనా చేసే ప్రతి నెట్‌వర్క్ కాల్ చుట్టూ try...except నిబంధనను చుట్టడం మరియు దాని స్థానంలో ఒక పిత్తి లోపం సందేశాన్ని ముద్రించడం.


And the idea of having big exception handlers that cover lots of code is the fourth and—in my opinion—best approach.

మరియు చాలా కోడ్‌ను కవర్ చేసే పెద్ద మినహాయింపు హ్యాండ్లర్‌లను కలిగి ఉండాలనే ఆలోచన నాల్గవది మరియు - నా అభిప్రాయం ప్రకారం - ఉత్తమ విధానం.


In long-running programs, this is common.

దీర్ఘకాలికంగా నడుస్తున్న ప్రోగ్రామ్‌లలో, ఇది సాధారణం.


For text, the big question will be choosing an encoding, so that the symbols you want to transmit can be changed into bytes.

వచనానికి, మీరు ప్రసారం చేయాలనుకుంటున్న చిహ్నాలను బైట్‌లుగా మార్చడానికి ఎన్‌కోడింగ్‌ను ఎంచుకోవడం పెద్ద ప్రశ్న అవుతుంది.


When you can ping another machine and get an answer in around 1.2 ms, you are on a pretty fast network.

మీరు మరొక యంత్రానికి పింగ్ చేసి, దాదాపు 1.2 msలో సమాధానం పొందగలిగితే, మీరు చాలా వేగవంతమైన నెట్‌వర్క్‌లో ఉన్నారు.


But the cost of the round-trip means that, if the server simply answers one question after another, then it can answer at most around 1,000 requests per second.

కానీ రౌండ్-ట్రిప్ ఖర్చు అంటే, సర్వర్ ఒకదాని తర్వాత ఒకటి ప్రశ్నలకు సమాధానం ఇస్తే, అది సెకనుకు 1,000 అభ్యర్థనలకు మించి సమాధానం ఇవ్వలేదు.


So the client and server both spend most of their time waiting.

అందువల్ల, క్లయింట్ మరియు సర్వర్ రెండూ తమ సమయాన్ని ఎక్కువగా ఎదురుచూస్తూ గడుపుతాయి.


A third observation is that the operating system is really very aggressive in taking tasks upon itself and letting the programs go ahead and get on with their lives.

మూడవ పరిశీలన ఏమిటంటే, ఆపరేటింగ్ సిస్టమ్ నిజంగా చాలా దూకుడుగా పనులను తీసుకుంటుంది మరియు ప్రోగ్రామ్‌లను ముందుకు సాగనిస్తుంది.


Look, for example, at how each sendall() call uses only a few dozen microseconds to queue up the data for transmission, and then lets the program proceed to its next instruction.

ఉదాహరణకు, ప్రతి sendall() కాల్ ప్రసారం కోసం డేటాను క్యూ చేయడానికి కొన్ని డజన్ల మైక్రో సెకన్లను మాత్రమే ఉపయోగిస్తుంది మరియు ప్రోగ్రామ్‌ను దాని తదుపరి సూచనకు వెళ్ళడానికి అనుమతిస్తుంది.


The operating system takes care of getting the data actually sent, without making the program wait.

ప్రోగ్రామ్‌ను వేచి ఉండకుండానే డేటాను పంపించే బాధ్యతను ఆపరేటింగ్ సిస్టమ్ చూసుకుంటుంది.


Finally, note the wide gulfs of time that are involved in simply setting up and tearing down the socket.

చివరగా, సాకెట్‌ను సెటప్ చేయడం మరియు కూల్చివేయడంలో పాల్గొన్న విస్తారమైన సమయాన్ని గమనించండి.


This leads to designers adding protocol features like the keep-alive mechanism of the HTTP/1.1 protocol.

ఇది డిజైనర్లు HTTP/1.1 ప్రోటోకాల్ యొక్క కీప్-అలైవ్ మెకానిజం వంటి ప్రోటోకాల్ లక్షణాలను జోడించడానికి దారి తీస్తుంది.


So if we talk to only one client at a time and patiently wait on the network to send and receive each request, then we can expect our servers to run hundreds or thousands of times more slowly.

కాబట్టి, మేము ఒక సమయంలో ఒక క్లయింట్‌తో మాత్రమే మాట్లాడి, ప్రతి అభ్యర్థనను పంపడానికి మరియు స్వీకరించడానికి నెట్‌వర్క్‌లో ఓపికగా వేచి ఉంటే, మా సర్వర్‌లు వందల లేదా వేల రెట్లు నెమ్మదిగా నడుస్తాయని మేము ఆశించవచ్చు.


Recall that a modern processor can often execute more than 2,000 machine-level instructions per microsecond.

ఒక ఆధునిక ప్రాసెసర్ తరచుగా సెకనుకు 2,000 కంటే ఎక్కువ మెషిన్-స్థాయి సూచనలను అమలు చేస్తుందని గుర్తుంచుకోండి.


That means that the 500 μs delay we discussed earlier leaves the server idle for nearly a half-million clock cycles before letting it continue work!

అంటే మనం ఇంతకు ముందు చర్చించిన 500 μs ఆలస్యం సర్వర్ పనిని కొనసాగించడానికి ముందు దాదాపు అర్ధ మిలియన్ క్లాక్ చక్రాల వరకు నిష్క్రియంగా ఉంచుతుంది!


Through the rest of this chapter, we will look at better ways to construct servers in view of these limitations.

ఈ అధ్యాయం అంతటా, ఈ పరిమితుల దృష్ట్యా సర్వర్‌లను నిర్మించడానికి మంచి మార్గాలను మేము పరిశీలిస్తాము.


Running a Benchmark Having used microsecond tracing to dissect a simple client and server, we are going to need a better system for comparing the subsequent server designs that we explore.

ఒక సాధారణ క్లయింట్ మరియు సర్వర్‌ను విశ్లేషించడానికి మైక్రో సెకండ్ ట్రేసింగ్‌ను ఉపయోగించిన తర్వాత, మేము అన్వేషించే తదుపరి సర్వర్ డిజైన్‌లను సరిపోల్చడానికి ఒక మంచి వ్యవస్థను పొందాలి.


Not only do we lack the space to print and analyze increasingly dense and convoluted timestamp traces, but that approach would make it very difficult to step back and to ask, “Which of these server designs is working the best?”

పెరుగుతున్న దట్టమైన మరియు గందరగోళ సమయ ముద్రణ జాడలను ముద్రించడానికి మరియు విశ్లేషించడానికి మాకు స్థలం లేదు, కానీ ఆ విధానం వెనుకకు వెళ్లి, “ఈ సర్వర్ డిజైన్‌లలో ఏది ఉత్తమంగా పనిచేస్తుంది?” అని అడగడం చాలా కష్టతరం చేస్తుంది.


We are therefore going to turn now to a public tool: the FunkLoad tool, written in Python and available from the Python Package Index.

అందువల్ల, మేము ఇప్పుడు ఒక పబ్లిక్ సాధనం వైపు తిరగబోతున్నాము: ఫంక్‌లోడ్ సాధనం, ఇది పైథాన్‌లో వ్రాయబడింది మరియు పైథాన్ ప్యాకేజీ ఇండెక్స్ నుండి అందుబాటులో ఉంది.


You can install it in a virtual environment with a simple command: $ pip install funkload

మీరు దీన్ని ఒక సాధారణ కమాండ్‌తో వర్చువల్ వాతావరణంలో ఇన్‌స్టాల్ చేయవచ్చు: $ pip install funkload


There are other popular benchmark tools available on the Web, including the “Apache bench” program named ab, but for this book it seemed that the leading Python load tester would be a good choice.

వెబ్‌లో “అపాచీ బెంచ్” ప్రోగ్రామ్ abతో సహా ఇతర ప్రసిద్ధ బెంచ్‌మార్క్ సాధనాలు అందుబాటులో ఉన్నాయి, అయితే ఈ పుస్తకం కోసం ప్రముఖ పైథాన్ లోడ్ టెస్టర్ మంచి ఎంపిక అనిపించింది.


FunkLoad can take a test routine and run more and more copies of it simultaneously to test how the resources it needs struggle with the rising load.

ఫంక్‌లోడ్ ఒక పరీక్షా రొటీన్‌ను తీసుకోవచ్చు మరియు పెరుగుతున్న లోడ్‌తో దానికి అవసరమైన వనరులు ఎలా పోరాడుతున్నాయో పరీక్షించడానికి ఒకేసారి ఎక్కువ కాపీలను అమలు చేయవచ్చు.


Our test routine will be an expanded version of the simple client that we used earlier: it will ask ten questions of the server instead of three, so that the network conversation itself will take up more time relative to the TCP setup and teardown times that come at the beginning and end.

మా పరీక్షా రొటీన్ మనం ఇంతకు ముందు ఉపయోగించిన సాధారణ క్లయింట్ యొక్క విస్తరించిన వెర్షన్: ఇది మూడు ప్రశ్నలకు బదులుగా సర్వర్‌ను పది ప్రశ్నలు అడుగుతుంది, తద్వారా నెట్‌వర్క్ సంభాషణే ప్రారంభంలో మరియు ముగింపులో వచ్చే TCP సెటప్ మరియు కూల్చివేసే సమయానికి సంబంధించి ఎక్కువ సమయం తీసుకుంటుంది.


The performance of our simple server Since we are sending ten Launcelot questions per test trial, the 325 test-per-second maximum that the simple server reaches represents 3,250 questions and answers—more than the 1,000 per second that we guessed were possible when testing server_simple.py over the slower SSH tunnel, but still of the same order of magnitude.

మా సాధారణ సర్వర్ పనితీరు మేము పరీక్షా విచారణకు పది లాన్సెలట్ ప్రశ్నలను పంపుతున్నందున, సాధారణ సర్వర్ చేరుకునే సెకనుకు 325 పరీక్షలు 3,250 ప్రశ్నలు మరియు సమాధానాలను సూచిస్తాయి—నెమ్మదిగా SSH టన్నెల్ ద్వారా server_simple.pyని పరీక్షిస్తున్నప్పుడు మేము ఊహించిన సెకనుకు 1,000 కంటే ఎక్కువ, కానీ ఇప్పటికీ అదే పరిమాణంలో ఉంది.


For example, the OpenSSL web site does (as we would expect!): $ python sslclient.py www.openssl.org

ఉదాహరణకు, OpenSSL వెబ్‌సైట్ చేస్తుంది (మనం ఊహించినట్లుగానే!): $ python sslclient.py www.openssl.org


The document https://www.openssl.org/ is 15941 bytes long

https://www.openssl.org/ పత్రం 15941 బైట్‌ల పొడవు ఉంది.


The Linksys router here at my house, by contrast, uses a self-signed certificate that can provide encryption but fails to provide a signature that can be verified against any of the famous CAs in the certfiles.crt file.

నా ఇంటి దగ్గర ఉన్న Linksys రౌటర్, దీనికి భిన్నంగా, ఎన్‌క్రిప్షన్ అందించగల స్వంత సంతకం చేసిన సర్టిఫికేట్‌ను ఉపయోగిస్తుంది, కానీ certfiles.crt ఫైల్‌లోని ప్రసిద్ధ CA లలో దేనితోనూ ధృవీకరించబడే సంతకాన్ని అందించడంలో విఫలమవుతుంది.


So, with the conservative settings in our sslclient.py program, the connection fails: $ python sslclient.py ten22.rhodesmill.org

కాబట్టి, మా sslclient.py ప్రోగ్రామ్‌లోని సంప్రదాయ సెట్టింగ్‌లతో, కనెక్షన్ విఫలమవుతుంది: $ python sslclient.py ten22.rhodesmill.org


Interestingly, Google (as of this writing) provides a single www.google.com certificate not only for that specific domain name, but also for its google.com address since all that is hosted there is a redirect to the www name:

ఆసక్తికరంగా, Google (ఈ సమయంలో) ఆ నిర్దిష్ట డొమైన్ పేరు కోసం మాత్రమే కాకుండా, దాని google.com చిరునామా కోసం కూడా ఒకే www.google.com సర్టిఫికేట్‌ను అందిస్తుంది, ఎందుకంటే అక్కడ హోస్ట్ చేయబడినదంతా www పేరుకు మళ్ళించబడుతుంది:


Writing an SSL server looks much the same: code like that in Listing 3-1 is supplemented so that the client socket returned by each accept() call gets immediately wrapped with wrap_socket(), but with different options than are used with a client.

SSL సర్వర్‌ను రాయడం దాదాపు ఒకేలా ఉంటుంది: జాబితా 3-1 లోని కోడ్ అనుబంధించబడింది, తద్వారా ప్రతి accept() కాల్ ద్వారా తిరిగి వచ్చే క్లయింట్ సాకెట్ వెంటనే wrap_socket()తో చుట్టబడుతుంది, అయితే క్లయింట్ ఉపయోగించే వాటి కంటే భిన్నమైన ఎంపికలతో.


In general, here are the three most popular ways of using wrap_socket() (see the ssl Standard Library documentation to learn about all of the rest of its options):

సాధారణంగా, wrap_socket()ని ఉపయోగించడానికి మూడు అత్యంత ప్రజాదరణ పొందిన మార్గాలు ఇక్కడ ఉన్నాయి (మిగిలిన అన్ని ఎంపికల గురించి తెలుసుకోవడానికి ssl స్టాండర్డ్ లైబ్రరీ డాక్యుమెంటేషన్‌ను చూడండి):


The first form is the one shown in Listing 6–1, and is the most common form of the call seen in clients: wrap_socket(sock, ssl_version=ssl. PROTOCOL_SSLv3, » cert_reqs=ssl. CERT_REQUIRED, ca_certs=ca_certs_path)

మొదటి రూపం జాబితా 6–1లో చూపబడింది మరియు ఇది క్లయింట్‌లలో కనిపించే కాల్ యొక్క అత్యంత సాధారణ రూపం: wrap_socket(sock, ssl_version=ssl. PROTOCOL_SSLv3, » cert_reqs=ssl. CERT_REQUIRED, ca_certs=ca_certs_path)


Here the client asserts no particular identity—at least, TLS provides no way for the server to know who is connecting.

ఇక్కడ క్లయింట్ నిర్దిష్ట గుర్తింపును పేర్కొనలేదు— కనీసం, ఎవరు కనెక్ట్ అవుతున్నారో తెలుసుకోవడానికి TLS సర్వర్‌కు మార్గం లేదు.


Servers generally do not care whether clients connect with certificates, so the wrap_socket() calls that they make after an accept() use a different set of named parameters that provide the documents that establish their own identity.

సాధారణంగా సర్వర్లు క్లయింట్‌లు సర్టిఫికెట్‌లతో కనెక్ట్ అవుతున్నాయా లేదా అనే దాని గురించి పట్టించుకోవు, కాబట్టి వారు accept() తర్వాత చేసే wrap_socket() కాల్‌లు వారి స్వంత గుర్తింపును ఏర్పాటు చేసే పత్రాలను అందించే వేరే పేరున్న పరామితుల సమితిని ఉపయోగిస్తాయి.


Finally, there do exist situations where you want to run a server that checks the certificates of the clients that are connecting.

చివరగా, మీరు కనెక్ట్ అవుతున్న క్లయింట్‌ల సర్టిఫికెట్‌లను తనిఖీ చేసే సర్వర్‌ను అమలు చేయాలనుకునే పరిస్థితులు ఉన్నాయి.


This can be useful if the protocol that you are wrapping provides weak or even non-existent authentication, and the TLS layer will be providing the only assurance about who is connecting.

మీరు చుట్టుముట్టే ప్రోటోకాల్ బలహీనమైన లేదా అస్తిత్వం లేని ప్రమాణీకరణను అందిస్తే ఇది ఉపయోగకరంగా ఉంటుంది మరియు ఎవరు కనెక్ట్ అవుతున్నారనే దాని గురించి TLS లేయర్ మాత్రమే హామీని అందిస్తుంది.


You will use your CA to sign client certificates for each individual or machine that will be connecting, then have your server make a call like this: wrap_socket(sock, server_side=True, ssl_version=ssl. PROTOCOL_SSLv23, » cert_reqs=ssl. CERT_REQUIRED, ca_certs=ca_certs_path, » keyfile="mykeyfile", certfile="mycertfile")

మీరు కనెక్ట్ అయ్యే ప్రతి వ్యక్తి లేదా మెషిన్ కోసం క్లయింట్ సర్టిఫికెట్‌లపై సంతకం చేయడానికి మీ CAని ఉపయోగిస్తారు, ఆపై మీ సర్వర్ ఇలాంటి కాల్ చేయండి: wrap_socket(sock, server_side=True, ssl_version=ssl. PROTOCOL_SSLv23, » cert_reqs=ssl. CERT_REQUIRED, ca_certs=ca_certs_path, » keyfile="mykeyfile", certfile="mycertfile")


Again, consult the ssl chapter in the Standard Library if you need to delve into the options more deeply; the documentation there has been getting quite a bit better, and might cover edge cases that we have not had room to discuss here in this chapter.

మళ్ళీ, మీరు ఎంపికలను మరింత లోతుగా పరిశోధించాలనుకుంటే, స్టాండర్డ్ లైబ్రరీలోని ssl అధ్యాయాన్ని సంప్రదించండి; అక్కడ ఉన్న డాక్యుమెంటేషన్ చాలా మెరుగ్గా ఉంది మరియు ఈ అధ్యాయంలో చర్చించడానికి మాకు స్థలం లేని అంచు కేసులను కవర్ చేయవచ్చు.


If you are writing clients and servers that need to talk only to each other, try using PROTOCOL_TLSv1 as your protocol.

మీరు ఒకరితో ఒకరు మాత్రమే మాట్లాడవలసిన క్లయింట్‌లు మరియు సర్వర్‌లను వ్రాస్తుంటే, మీ ప్రోటోకాల్‌గా PROTOCOL_TLSv1ని ఉపయోగించడానికి ప్రయత్నించండి.


It is more modern and secure than any of the protocols that have SSL in their names.

ఇది SSLని కలిగి ఉన్న ప్రోటోకాల్‌ల కంటే ఆధునికమైనది మరియు సురక్షితమైనది.


The only reason to use SSL protocols—as shown in the foregoing example calls, and which are also currently CHAPTER 6 ■ TLS AND SSL 98 the defaults for the wrap_socket() call in the Standard Library—is if you need to speak to browsers or other third-party clients that might not have upgraded to full-fledged TLS yet.

SSL ప్రోటోకాల్‌లను ఉపయోగించడానికి ఏకైక కారణం—ముందు ఉదాహరణ కాల్‌లలో చూపిన విధంగా, మరియు ప్రస్తుతం చాప్టర్ 6 ■ TLS మరియు SSL 98 స్టాండర్డ్ లైబ్రరీలోని wrap_socket() కాల్ కోసం డిఫాల్ట్‌లు—మీరు బ్రౌజర్‌లతో లేదా పూర్తి స్థాయి TLSకి అప్‌గ్రేడ్ చేయని ఇతర మూడవ పక్ష క్లయింట్‌లతో మాట్లాడవలసి వస్తే.


Loose Ends When adding cryptography to your application, it is always a good idea to read up-to-date documentation.

మీ అప్లికేషన్‌కు క్రిప్టోగ్రఫీని జోడించేటప్పుడు, తాజాగా ఉన్న డాక్యుమెంటేషన్‌ను చదవడం ఎల్లప్పుడూ మంచిది.


The advice given in this chapter would have been quite different if this revision of the book had happened even just one or two years earlier, and in two or three more years it will doubtless be out of date.

ఈ అధ్యాయంలో ఇచ్చిన సలహా, పుస్తకం యొక్క ఈ పునర్విమర్శ ఒకటి లేదా రెండు సంవత్సరాల ముందు జరిగి ఉంటే చాలా భిన్నంగా ఉండేది మరియు మరో రెండు లేదా మూడు సంవత్సరాలలో ఇది నిస్సందేహంగా కాలం చెల్లినది.


Imagine that you run a typical web service consisting of front-end machines that serve HTML to customers and a back-end database that powers your service, and that all communication over your network is cleartext.

మీరు కస్టమర్‌లకు HTMLని అందించే ఫ్రంట్-ఎండ్ మెషీన్‌లతో కూడిన ఒక సాధారణ వెబ్ సేవను నడుపుతున్నారని ఊహించుకోండి మరియు మీ సేవను నడిపించే బ్యాక్-ఎండ్ డేటాబేస్ మరియు మీ నెట్‌వర్క్‌లో జరిగే అన్ని కమ్యూనికేషన్ స్పష్టంగా ఉన్నాయి.


This activity is called “network sniffing,” and is quite legitimate when performed by network administrators trying to fix problems on their own hardware.

ఈ కార్యాన్ని “నెట్‌వర్క్ స్నిఫింగ్” అని పిలుస్తారు మరియు నెట్‌వర్క్ నిర్వాహకులు వారి స్వంత హార్డ్‌వేర్‌పై సమస్యలను పరిష్కరించడానికి ప్రయత్నించినప్పుడు ఇది చాలా చట్టబద్ధమైనది.


The traditional program tcpdump and the more sleek and modern wireshark are both good tools if you want to try observing some network packets yourself.

మీరు కొన్ని నెట్‌వర్క్ ప్యాకెట్‌లను మీరే గమనించడానికి ప్రయత్నించాలనుకుంటే, సాంప్రదాయ ప్రోగ్రామ్ tcpdump మరియు మరింత సొగసైన మరియు ఆధునిక వైర్‌షార్క్ రెండూ మంచి సాధనాలు.


Perhaps the adversary is sitting in a coffee shop, and he has a wireless card that is collecting your traffic as you debug one of the servers, and he keeps it for later analysis.

బహుశా ప్రత్యర్థి ఒక కాఫీ షాప్‌లో కూర్చుని ఉండవచ్చు మరియు మీరు సర్వర్లలో ఒకదాన్ని డీబగ్ చేస్తున్నప్పుడు మీ ట్రాఫిక్‌ను సేకరించే వైర్‌లెస్ కార్డ్ అతని వద్ద ఉంది మరియు అతను దానిని తరువాత విశ్లేషణ కోసం ఉంచుకుంటాడు.


He will see any usernames and passwords that your clients use to connect to the servers behind them.

మీ క్లయింట్‌లు వాటి వెనుక ఉన్న సర్వర్‌లకు కనెక్ట్ అవ్వడానికి ఉపయోగించే ఏదైనా వినియోగదారు పేర్లు మరియు పాస్‌వర్డ్‌లను అతను చూస్తాడు.


Log messages can also be intercepted, if they are being sent to a central location and happen to travel over a compromised IP segment or device.

లాగ్ సందేశాలను కూడా అడ్డుకోవచ్చు, అవి కేంద్ర స్థానానికి పంపబడితే మరియు రాజీపడిన IP విభాగం లేదా పరికరం ద్వారా ప్రయాణిస్తే.


If your database server is not picky about who connects, aside from caring that the web front end sends a password, then the attacker can now launch a “replay attack,”

మీ డేటాబేస్ సర్వర్ ఎవరు కనెక్ట్ అవుతున్నారనే దాని గురించి పిరికివాడు కాకపోతే, వెబ్ ఫ్రంట్ ఎండ్ పాస్‌వర్డ్‌ను పంపుతుందనే దాని గురించి పట్టించుకోకుండా, అప్పుడు దాడి చేసే వ్యక్తి ఇప్పుడు “రీప్లే దాడి”ని ప్రారంభించవచ్చు.


When your front ends ask for the hostname db.example.com, she could answer with the IP address of her own server, located anywhere in the world, instead.

మీ ఫ్రంట్ ఎండ్‌లు హోస్ట్‌నేమ్ db.example.com కోసం అడిగినప్పుడు, ఆమె ప్రపంచంలో ఎక్కడైనా ఉన్న తన స్వంత సర్వర్ యొక్క IP చిరునామాతో సమాధానం ఇవ్వవచ్చు.


This is called a “man-in-the-middle” attack.

దీనిని “మధ్యలో ఉన్న వ్యక్తి” దాడి అంటారు.


The secret to TLS is public-key cryptography, one of the great computing advances of the last few decades, and one of the very few areas of innovation in which academic computer science really shows its worth.

TLS రహస్యం పబ్లిక్-కీ క్రిప్టోగ్రఫీ, ఇది గత కొన్ని దశాబ్దాల గొప్ప కంప్యూటింగ్ పురోగతులలో ఒకటి మరియు అకాడెమిక్ కంప్యూటర్ సైన్స్ నిజంగా దాని విలువను చూపే కొన్ని ఆవిష్కరణలలో ఒకటి.


If the public key is used to encrypt information, then the resulting block of binary data cannot be read by anyone, anywhere in the world, except by someone who holds the private key.

సమాచారాన్ని గుప్తీకరించడానికి పబ్లిక్ కీని ఉపయోగిస్తే, ఫలితంగా వచ్చే బైనరీ డేటా బ్లాక్‌ను ప్రైవేట్ కీని కలిగి ఉన్న వ్యక్తి తప్ప ప్రపంచంలో ఎవరూ ఎక్కడైనా చదవలేరు.


Here, we will focus on how public keys are used in the TLS system.

ఇక్కడ, TLS సిస్టమ్‌లో పబ్లిక్ కీలను ఎలా ఉపయోగిస్తారో దానిపై మేము దృష్టి పెడతాము.


Traditional symmetric-key encryption, where both sides share a big random block of data with which they encrypt outgoing traffic and decrypt incoming traffic, is much faster and better at handling large payloads.

సాంప్రదాయ సిమెట్రిక్-కీ ఎన్‌క్రిప్షన్, ఇక్కడ రెండు వైపులా పెద్ద యాదృచ్ఛిక డేటా బ్లాక్‌ను పంచుకుంటాయి, దానితో వారు అవుట్‌గోయింగ్ ట్రాఫిక్‌ను గుప్తీకరిస్తారు మరియు ఇన్‌కమింగ్ ట్రాఫిక్‌ను డీక్రిప్ట్ చేస్తారు, ఇది చాలా వేగంగా ఉంటుంది మరియు పెద్ద పేలోడ్‌లను నిర్వహించడంలో మెరుగ్గా ఉంటుంది.


So TLS uses public-key cryptography only to begin each conversation: the server sends a public key to the client, the client sends back a suitable symmetric key by encrypting it with the public key, and now both sides hold the same symmetric key without an observer ever having been given the chance to capture it—since the observer will not be able to derive (thanks to powerful mathematics!) the server's private key based on seeing the public key go one way and an encrypted block of data going the other.

కాబట్టి TLS ప్రతి సంభాషణను ప్రారంభించడానికి మాత్రమే పబ్లిక్-కీ క్రిప్టోగ్రఫీని ఉపయోగిస్తుంది: సర్వర్ క్లయింట్‌కు పబ్లిక్ కీని పంపుతుంది, క్లయింట్ పబ్లిక్ కీతో గుప్తీకరించడం ద్వారా తగిన సిమెట్రిక్ కీని తిరిగి పంపుతుంది మరియు ఇప్పుడు ఇరువైపులా ఒకే సిమెట్రిక్ కీని కలిగి ఉంటాయి, గమనించేవారు దానిని సంగ్రహించే అవకాశం ఇవ్వబడలేదు—గమనించేవారు సర్వర్ యొక్క ప్రైవేట్ కీని పొందలేరు (శక్తివంతమైన గణితానికి ధన్యవాదాలు!) పబ్లిక్ కీ ఒక మార్గంలో వెళ్లడం మరియు గుప్తీకరించబడిన డేటా బ్లాక్ మరొక విధంగా వెళ్లడం ఆధారంగా.


That alone protects your traffic against sniffing, since an attacker cannot see any of your data by watching from outside, and it also means that he cannot insert, delete, or alter the packets passing across a network node since, without the symmetric key, any change he makes to the data will simply produce gibberish when decrypted.

ఒక దాడి చేసే వ్యక్తి బయటి నుండి చూసి మీ డేటాను చూడలేనందున, అది ఒక్కటే మీ ట్రాఫిక్‌ను స్నిఫింగ్ నుండి రక్షిస్తుంది మరియు సిమెట్రిక్ కీ లేకుండా, అతను డేటాకు చేసే ఏదైనా మార్పు డీక్రిప్ట్ చేసినప్పుడు కేవలం గిబ్బరిష్‌ను ఉత్పత్తి చేస్తుంది కాబట్టి, నెట్‌వర్క్ నోడ్ ద్వారా వెళ్ళే ప్యాకెట్‌లను అతను చొప్పించలేడు, తొలగించలేడు లేదా మార్చలేడు.


Do you remember that the server end of a TLS connection starts by sharing a public key with the client?

TLS కనెక్షన్ యొక్క సర్వర్ ముగింపు క్లయింట్‌తో పబ్లిక్ కీని పంచుకోవడం ద్వారా ప్రారంభమవుతుందని మీకు గుర్తున్నాయా?


If he does not return to you the server's real certificate, then it will not really have been signed by the CA and your TLS library will tell you he is a fake; or, if the attacker does return the server's certificate—since, after all, it is publicly transmitted on the network—then your client will indeed be willing to start talking.

అతను మీకు సర్వర్ యొక్క అసలు సర్టిఫికేట్‌ను తిరిగి ఇవ్వకపోతే, అది నిజంగా CA ద్వారా సంతకం చేయబడదు మరియు మీ TLS లైబ్రరీ అతను నకిలీ అని మీకు చెబుతుంది; లేదా, దాడి చేసే వ్యక్తి సర్వర్ యొక్క సర్టిఫికేట్‌ను తిరిగి ఇస్తే—అన్నింటికంటే, ఇది నెట్‌వర్క్‌లో బహిరంగంగా ప్రసారం చేయబడుతుంది—అప్పుడు మీ క్లయింట్ నిజంగా మాట్లాడటానికి సిద్ధంగా ఉంటాడు.


These companies stake their reputations on keeping their private keys absolutely safe, and signing server certificates only after making absolutely sure that the request really comes from the owner of a given domain.

ఈ కంపెనీలు తమ ప్రైవేట్ కీలను పూర్తిగా సురక్షితంగా ఉంచడంపై మరియు అభ్యర్థన నిజంగా ఇచ్చిన డొమైన్ యజమాని నుండి వస్తుందని పూర్తిగా నిర్ధారించిన తర్వాత మాత్రమే సర్వర్ సర్టిఫికేట్‌లపై సంతకం చేయడంపై తమ ఖ్యాతిని పణంగా పెడతాయి.


If you are setting up TLS servers that will be contacted only by clients that you configure, then you can save money by bypassing the public CAs and generating your own CA public-private key pair.

మీరు కాన్ఫిగర్ చేసే క్లయింట్‌ల ద్వారా మాత్రమే సంప్రదించబడే TLS సర్వర్‌లను ఏర్పాటు చేస్తుంటే, మీరు పబ్లిక్ CAsని దాటవేయడం ద్వారా మరియు మీ స్వంత CA పబ్లిక్-ప్రైవేట్ కీ జతను రూపొందించడం ద్వారా డబ్బు ఆదా చేయవచ్చు.


The procedure is simple and is shown in Listing 6–1.

విధానం సులభం మరియు జాబితా 6–1లో చూపబడింది.


You might get a string from one client, then have to finish sending an answer to a second client.

మీరు ఒక క్లయింట్ నుండి ఒక స్ట్రింగ్ పొందవచ్చు, ఆపై రెండవ క్లయింట్కు సమాధానం పంపడం పూర్తి చేయాలి.


So we can grudgingly admit that there is a “soft asynchrony” here.

కాబట్టి ఇక్కడ “మెత్తటి అసమకాలికత” ఉందని మనం అంగీకరించవచ్చు.


In the same way, understanding the UTF-8 string encoding is useful, but sitting down to write your own encoder in Python is probably a sign that you are re-inventing a wheel.

అదే విధంగా, UTF-8 స్ట్రింగ్ ఎన్కోడింగ్‌ను అర్థం చేసుకోవడం ఉపయోగకరంగా ఉంటుంది, కానీ పైథాన్‌లో మీ స్వంత ఎన్‌కోడర్‌ను రాయడానికి కూర్చోవడం బహుశా మీరు చక్రం తిరిగి కనుగొంటున్నారనడానికి సంకేతం.


It is a pair of ancient modules, asyncore and asynchat, that date from the early days of Python.

ఇది పురాతన మాడ్యూల్స్ జత, asyncore మరియు asynchat, ఇవి పైథాన్ ప్రారంభ రోజుల నాటివి.


If you are curious about these old parts of the Standard Library, then download the source bundle for this book.

మీకు స్టాండర్డ్ లైబ్రరీ యొక్క ఈ పాత భాగాల గురించి ఆసక్తి ఉంటే, ఈ పుస్తకం కోసం సోర్స్ బండిల్‌ను డౌన్‌లోడ్ చేయండి.


Twisted Python is not simply a framework; it is almost something of a movement.

ట్విస్టెడ్ పైథాన్ కేవలం ఒక ఫ్రేమ్‌వర్క్ కాదు; ఇది దాదాపు ఒక ఉద్యమం వంటిది.


Take a look at Listing 7–8 for how simple our event-driven server can become.

మన ఈవెంట్-డ్రివెన్ సర్వర్ ఎంత సరళంగా మారగలదో తెలుసుకోవడానికి జాబితా 7–8ని చూడండి.


From then on, every event on that socket is translated into a method call to our object.

అప్పటి నుండి, ఆ సాకెట్‌లోని ప్రతి ఈవెంట్ మన ఆబ్జెక్ట్‌కు పద్ధతి కాల్‌గా అనువదించబడుతుంది.


But what stops the server from blocking when we call the write() me thod of our data transport?

కానీ మన డేటా రవాణా యొక్క write() పద్ధతిని పిలిచినప్పుడు సర్వర్ బ్లాక్ అవ్వకుండా ఏమి ఆపుతుంది?


There are more methods available on a Twisted Protocol class than we are using here.

మేము ఇక్కడ ఉపయోగిస్తున్న దానికంటే ట్విస్టెడ్ ప్రోటోకాల్ క్లాస్‌లో మరిన్ని పద్ధతులు అందుబాటులో ఉన్నాయి.


The performance of Twisted, as you can see from Figure 7–3, is somewhat lower than that of our handwritten event loop.

మీరు చిత్రం 7–3 నుండి చూడగలిగినట్లుగా, ట్విస్టెడ్ పనితీరు మన చేతితో రాసిన ఈవెంట్ లూప్ కంటే కొంచెం తక్కువగా ఉంది.


The real magic of Twisted—which we lack the space to explore here—happens when you write protocols that have to speak to several partners at once rather than just one.

ట్విస్టెడ్ యొక్క అసలైన మాయాజాలం—దీనిని ఇక్కడ అన్వేషించడానికి మాకు స్థలం లేదు—మీరు ఒకేసారి ఒకటి కంటే ఎక్కువ భాగస్వాములతో మాట్లాడవలసిన ప్రోటోకాల్‌లను రాసినప్పుడు జరుగుతుంది.


But what if generating an answer involved reading from disk, or querying another network service, or talking to a local database?

కానీ సమాధానం రూపొందించడంలో డిస్క్ నుండి చదవడం, లేదా మరొక నెట్‌వర్క్ సేవను ప్రశ్నించడం లేదా స్థానిక డేటాబేస్‌తో మాట్లాడటం వంటివి ఉంటే?


Error handling becomes the practice of making sure that appropriate error callbacks are always available in case any particular network or I/O operation fails.

ఏదైనా నిర్దిష్ట నెట్‌వర్క్ లేదా I/O ఆపరేషన్ విఫలమైతే తగిన ఎర్రర్ కాల్‌బ్యాక్‌లు ఎల్లప్పుడూ అందుబాటులో ఉండేలా చూసుకోవడమే ఎర్రర్ హ్యాండ్లింగ్.


The answer, obviously, is to run several instances of your service and to distribute clients among them.

సమాధానం, స్పష్టంగా, మీ సేవ యొక్క అనేక ఉదాహరణలను అమలు చేయడం మరియు వాటి మధ్య క్లయింట్‌లను పంపిణీ చేయడం.


This requires a key piece of software: a load balancer that runs on the port to which all of the clients will be connecting.

దీనికి ఒక ముఖ్యమైన సాఫ్ట్‌వేర్ అవసరం: అన్ని క్లయింట్‌లు కనెక్ట్ అయ్యే పోర్ట్‌లో నడుస్తున్న లోడ్ బ్యాలెన్సర్.


Load balancers are such critical pieces of infrastructure that they are often built directly into network hardware.

లోడ్ బ్యాలెన్సర్‌లు మౌలిక సదుపాయాలలో చాలా కీలకమైన భాగాలు, అవి తరచుగా నేరుగా నెట్‌వర్క్ హార్డ్‌వేర్‌లో నిర్మించబడతాయి.


In the old days, it was common to spread load by simply giving a single domain name several different IP addresses.

పాత రోజుల్లో, ఒకే డొమైన్ పేరుకు అనేక విభిన్న IP చిరునామాలను ఇవ్వడం ద్వారా లోడ్‌ను వ్యాప్తి చేయడం సాధారణం.


The essential idea of a threaded or multi-process server is that we take the simple and straightforward server that we started out with.

థ్రెడెడ్ లేదా మల్టీ-ప్రాసెస్ సర్వర్ యొక్క ముఖ్యమైన ఆలోచన ఏమిటంటే, మనం ప్రారంభించిన సాధారణ మరియు సూటిగా ఉండే సర్వర్‌ను తీసుకోవడం.


Each thread controls one client socket; it can use blocking recv() and send() calls to wait until data can be received and transmitted.

ప్రతి థ్రెడ్ ఒక క్లయింట్ సాకెట్‌ను నియంత్రిస్తుంది; డేటాను స్వీకరించడానికి మరియు ప్రసారం చేయడానికి వేచి ఉండటానికి ఇది బ్లాకింగ్ recv() మరియు send() కాల్‌లను ఉపయోగించవచ్చు.


You are embarking, instead, on an entire discipline of its own known as “concurrent programming,”

మీరు బదులుగా, “సమకాలీన ప్రోగ్రామింగ్” అని పిలువబడే ఒక ప్రత్యేక విభాగంలోకి ప్రవేశిస్తున్నారు.


First, make sure that you have the difference between threads and processes clear in your head.

ముందుగా, థ్రెడ్‌లు మరియు ప్రక్రియల మధ్య వ్యత్యాసాన్ని మీ మనస్సులో స్పష్టంగా ఉంచుకోండి.


But if your workers need to talk to one another, then threads let them do so in-memory

కానీ మీ కార్మికులు ఒకరితో ఒకరు మాట్లాడవలసి వస్తే, థ్రెడ్‌లు వాటిని మెమరీలో చేయడానికి అనుమతిస్తాయి.


Second, use high-level data structures whenever possible.

రెండవది, వీలైతే, అధిక-స్థాయి డేటా నిర్మాణాలను ఉపయోగించండి.


Python provides queues, for example, that can operate either between normal threads (from the queue module) or between processes (see the multiprocessing module).

ఉదాహరణకు, పైథాన్ క్యూలను అందిస్తుంది, ఇవి సాధారణ థ్రెడ్‌ల మధ్య (క్యూ మాడ్యూల్ నుండి) లేదా ప్రక్రియల మధ్య (మల్టీప్రాసెసింగ్ మాడ్యూల్‌ను చూడండి) పనిచేయగలవు.


Third, limit your use of shared data to small and easily protected pieces of code.

మూడవది, భాగస్వామ్య డేటాను చిన్న మరియు సులభంగా రక్షించబడే కోడ్ ముక్కలకు పరిమితం చేయండి.


Choose a few conceptually small points of synchronization where the gears of your program will mesh together, and do your hard thinking there in one place to make sure that your program will operate correctly.

మీ ప్రోగ్రామ్ యొక్క గేర్లు కలిసిపోయే కొన్ని భావనాత్మకంగా చిన్న సమకాలీకరణ పాయింట్లను ఎంచుకోండి మరియు మీ ప్రోగ్రామ్ సరిగ్గా పనిచేస్తుందని నిర్ధారించుకోవడానికి ఒకే స్థలంలో కష్టపడి ఆలోచించండి.


Finally, look very hard at both the Standard Library and the Package Index for evidence that some other programmer before you has faced the data pattern you are trying to implement and has already taken the time to get it right.

చివరగా, మీరు అమలు చేయడానికి ప్రయత్నిస్తున్న డేటా నమూనాను మీ ముందు కొంతమంది ఇతర ప్రోగ్రామర్లు ఎదుర్కొన్నారనడానికి మరియు దానిని సరిగ్గా పొందడానికి ఇప్పటికే సమయం తీసుకున్నారనడానికి స్టాండర్డ్ లైబ్రరీ మరియు ప్యాకేజీ ఇండెక్స్‌ను చాలా జాగ్రత్తగా చూడండి.


That, I believe, is the way to go about writing network services: write code that concerns itself with local variables and local effects, and that leaves all of the issues of locking and concurrency to people like database designers that are good at that sort of thing.

నెట్‌వర్క్ సేవలను ఎలా రాయాలనే దాని గురించి నేను నమ్ముతున్నాను: స్థానిక వేరియబుల్స్ మరియు స్థానిక ప్రభావాలతో సంబంధం ఉన్న కోడ్‌ను రాయండి మరియు లాకింగ్ మరియు కన్కరెన్సీకి సంబంధించిన అన్ని సమస్యలను డేటాబేస్ డిజైనర్‌ల వంటి వ్యక్తులకు వదిలివేయండి.


Back then, the RAM used by each running process was a substantial annoyance.

అప్పట్లో, ప్రతి రన్నింగ్ ప్రాసెస్ ఉపయోగించే RAM ఒక ముఖ్యమైన అసౌకర్యం.


Today, of course, even the Ubuntu laptop on which I am typing is running dozens of services just to power things like the weather widget in my toolbar, and the machine’s response time seems downright snappy despite running—let’s see—wow, 229 separate processes all at the same time.

నేడు, నేను టైప్ చేస్తున్న ఉబుంటు ల్యాప్‌టాప్ కూడా నా టూల్‌బార్‌లోని వాతావరణ విడ్జెట్ వంటి వాటిని శక్తివంతం చేయడానికి డజన్ల కొద్దీ సేవలను నడుపుతోంది మరియు మెషిన్ యొక్క ప్రతిస్పందన సమయం నడుస్తున్నప్పటికీ చాలా వేగంగా ఉంది—చూద్దాం—వావ్, ఒకే సమయంలో 229 ప్రత్యేక ప్రక్రియలు.


So the idea was to have an /etc/inetd.conf file where you could list all of the services you wanted to provide, along with the name of the program that should be run to answer each request.

కాబట్టి మీరు అందించాలనుకుంటున్న అన్ని సేవల జాబితాను కలిగి ఉండే /etc/inetd.conf ఫైల్‌ను కలిగి ఉండాలనే ఆలోచన, ప్రతి అభ్యర్థనకు సమాధానం ఇవ్వడానికి అమలు చేయవలసిన ప్రోగ్రామ్ పేరుతో పాటు.


If you are writing a Python service to be run from inetd, the client socket returned by the inetd accept() call will be passed in as your standard input and output.

మీరు inetd నుండి అమలు చేయడానికి పైథాన్ సేవను రాస్తుంటే, inetd accept() కాల్ ద్వారా తిరిగి వచ్చిన క్లయింట్ సాకెట్ మీ ప్రామాణిక ఇన్‌పుట్ మరియు అవుట్‌పుట్‌గా అందించబడుతుంది.


Network servers typically need to run as daemons so that they do not exit when a particular user logs out, and since they will have no controlling terminal, they will need to log their activity to files so that administrators can monitor and debug them.

నెట్‌వర్క్ సర్వర్‌లు సాధారణంగా డీమన్‌లుగా అమలు చేయవలసి ఉంటుంది, తద్వారా ఒక నిర్దిష్ట వినియోగదారు లాగ్ అవుట్ అయినప్పుడు అవి నిష్క్రమించవు మరియు వాటికి నియంత్రణ టెర్మినల్ ఉండదు కాబట్టి, నిర్వాహకులు వాటిని పర్యవేక్షించడానికి మరియు డీబగ్ చేయడానికి వాటి కార్యాచరణను ఫైల్‌లకు లాగ్ చేయాలి.


One approach to network programming is to write an event-driven program, or use an event-driven framework like Twisted Python.

నెట్‌వర్క్ ప్రోగ్రామింగ్‌కు ఒక విధానం ఏమిటంటే, ఈవెంట్-డ్రివెన్ ప్రోగ్రామ్‌ను రాయడం లేదా ట్విస్టెడ్ పైథాన్ వంటి ఈవెంట్-డ్రివెన్ ఫ్రేమ్‌వర్క్‌ను ఉపయోగించడం.


Threads are a weak solution under C Python because the Global Interpreter Lock prevents any two of them from both running Python code at the same time

C పైథాన్ కింద థ్రెడ్‌లు బలహీనమైన పరిష్కారం, ఎందుకంటే గ్లోబల్ ఇంటర్‌ప్రెటర్ లాక్ వాటిలో రెండింటినీ ఒకే సమయంలో పైథాన్ కోడ్‌ను అమలు చేయకుండా నిరోధిస్తుంది.


In ancient times, people ran network services through inetd, which hands each server an already- accepted client connection as its standard input and output.

పురాతన కాలంలో, ప్రజలు నెట్‌వర్క్ సేవలను inetd ద్వారా నడిపించారు, ఇది ఇప్పటికే అంగీకరించబడిన క్లయింట్ కనెక్షన్‌ను ప్రతి సర్వర్‌కు దాని ప్రామాణిక ఇన్‌పుట్ మరియు అవుట్‌పుట్‌గా అందిస్తుంది.


Its impact on many large Internet services has been, by all accounts, revolutionary.

అనేక పెద్ద ఇంటర్నెట్ సేవలపై దాని ప్రభావం, అన్ని ఖాతాల ద్వారా, విప్లవాత్మకంగా ఉంది.


You run a Memcached daemon on every server with some spare memory.

మీరు కొంత ఖాళీ మెమరీతో ప్రతి సర్వర్‌లో Memcached డీమన్‌ను అమలు చేస్తారు.


Your client programs now have access to an organization-wide blazing-fast key- value cache that acts something like a big Python dictionary that all of your servers can share.

మీ క్లయింట్ ప్రోగ్రామ్‌లు ఇప్పుడు సంస్థ-వ్యాప్త బ్లేజింగ్-ఫాస్ట్ కీ-విలువ కాష్‌ను యాక్సెస్ చేయగలవు, ఇది మీ సర్వర్లన్నీ భాగస్వామ్యం చేయగల పెద్ద పైథాన్ నిఘంటువులా పనిచేస్తుంది.


The GET method is still the backbone of the protocol today.

ఈ రోజుకీ GET పద్ధతి ప్రోటోకాల్ యొక్క వెన్నెముకగా ఉంది.


It is very important to get this boundary strictly correct when writing an HTTP implementation.

ఒక HTTP అమలును రాసేటప్పుడు ఈ సరిహద్దును ఖచ్చితంగా సరిగ్గా పొందడం చాలా ముఖ్యం.


Web servers, in practice, have absolute freedom to interpret URLs as they please.

వెబ్ సర్వర్లు, ఆచరణలో, URLలను తమకు నచ్చిన విధంగా అర్థం చేసుకునే పూర్తి స్వేచ్ఛను కలిగి ఉంటాయి.


The simplest relative links are the names of pages one level deeper than the base page.

అతి సాధారణ సంబంధిత లింక్‌లు బేస్ పేజీ కంటే ఒక స్థాయి లోతులో ఉన్న పేజీల పేర్లు.


This indicates that each page was fetched successfully.

ప్రతి పేజీ విజయవంతంగా పొందబడిందని ఇది సూచిస్తుంది.


అభ్యర్థన విజయవంతమైంది.


The resource that used to live at this URL has been assigned a new URL.

ఈ URLలో నివసించిన వనరుకు కొత్త URL కేటాయించబడింది.


The original URL should continue to be used for this request.

ఈ అభ్యర్థన కోసం అసలు URLని ఉపయోగించడం కొనసాగించాలి.


URL చెల్లుబాటు అయ్యే వనరు పేరును సూచించదు.


వెబ్‌సైట్ పనిచేయడం లేదు.


This is the code included when Twitter displays its famous Fail Whale, for example.

ఉదాహరణకు, Twitter దాని ప్రసిద్ధ ఫెయిల్ వేల్‌ను ప్రదర్శించినప్పుడు చేర్చబడిన కోడ్ ఇది.


By catching the exception, we can both see how the HTTP response looked on the wire.

అసాధారణ పరిస్థితిని పట్టుకోవడం ద్వారా, తీగపై HTTP ప్రతిస్పందన ఎలా ఉందో మనం చూడవచ్చు.


Redirections are very common on the World Wide Web.

ప్రపంచవ్యాప్త వెబ్‌లో దారిమార్పులు చాలా సాధారణం.


Google, for example, likes those three letters to be included.

ఉదాహరణకు, Google ఆ మూడు అక్షరాలను చేర్చడానికి ఇష్టపడుతుంది.


You cannot tell by looking at the response whether a redirect occurred.

పునరుద్ధరణ జరిగిందా లేదా అని ప్రతిస్పందనను చూడటం ద్వారా మీరు చెప్పలేరు.


Keep in mind that downloading a modern web page

ఒక ఆధునిక వెబ్ పేజీని డౌన్‌లోడ్ చేస్తున్నప్పుడు గుర్తుంచుకోండి


For example, consider a very simple URL like the following: http://python.org

ఉదాహరణకు, కింది విధంగా చాలా సాధారణ URLని పరిగణించండి: http://python.org


The hostname example.com will be resolved to an IP.

హోస్ట్‌నేమ్ example.com IPకి పరిష్కరించబడుతుంది.


Any characters beyond the alphanumerics must be percent-encoded.

ఆల్ఫాన్యూమరిక్‌లకు మించిన ఏదైనా అక్షరాలను శాతం-ఎన్‌కోడ్ చేయాలి.


This is because any anchor is stripped off and is not turned into part of the HTTP request.

ఎందుకంటే ఏదైనా యాంకర్‌ను తీసివేయబడుతుంది మరియు HTTP అభ్యర్థనలో భాగంగా మార్చబడదు.


The pipeline makes sure that every queued message is delivered to exactly one consumer.

ప్రతి క్యూలో ఉన్న సందేశం ఖచ్చితంగా ఒక వినియోగదారునికి మాత్రమే డెలివరీ చేయబడుతుందని పైప్‌లైన్ నిర్ధారిస్తుంది.


But subscribers typically want to receive all of the messages that are being enqueued by each publisher.

కానీ సాధారణంగా, చందాదారులు ప్రతి ప్రచురణకర్త ద్వారా క్యూలో ఉంచబడుతున్న అన్ని సందేశాలను స్వీకరించాలనుకుంటారు.


This kind of queue can be used to power external services that need to push events to the outside world.

ఈ రకమైన క్యూ ఈవెంట్‌లను బయటి ప్రపంచానికి పంపించాల్సిన బాహ్య సేవలకు శక్తినివ్వడానికి ఉపయోగించవచ్చు.


Finally, a request-reply pattern is often the most complex because messages have to make a round- trip.

చివరగా, అభ్యర్థన-ప్రత్యుత్తర నమూనా తరచుగా చాలా క్లిష్టమైనది, ఎందుకంటే సందేశాలు రౌండ్-ట్రిప్ చేయాలి.


The queue itself, to support this, has to feature some sort of addressing scheme.

దీనికి మద్దతు ఇవ్వడానికి, క్యూలో ఏదో ఒక రకమైన చిరునామా పథకం ఉండాలి.


Request-reply queues are a great way to connect lightweight workers.

అభ్యర్థన-ప్రత్యుత్తర క్యూలు తేలికైన కార్మికులను కనెక్ట్ చేయడానికి గొప్ప మార్గం.


Messaging seems to have been popular in the Java world before it started becoming the rage among Python programmers.

పైథాన్ ప్రోగ్రామర్‌లలో ఇది ఒక క్రేజ్‌గా మారడానికి ముందే జావా ప్రపంచంలో సందేశం బాగా ప్రాచుర్యం పొందినట్లు అనిపిస్తుంది.


A competing approach that is much more in line with the Internet philosophy of open standards.

ఓపెన్ స్టాండర్డ్స్ యొక్క ఇంటర్నెట్ తత్వశాస్త్రానికి అనుగుణంగా ఉన్న పోటీ విధానం.


There are several AMQP implementations currently listed in the Python Package Index.

ప్రస్తుతం పైథాన్ ప్యాకేజీ ఇండెక్స్‌లో అనేక AMQP అమలులు జాబితా చేయబడ్డాయి.


Future readers will want to read recent blog posts and success stories.

భవిష్యత్ పాఠకులు ఇటీవలి బ్లాగ్ పోస్ట్‌లు మరియు విజయ కథలను చదవాలనుకుంటున్నారు.


An alternative to using AMQP and having to run a central broker is to use ØMQ.

AMQPని ఉపయోగించడానికి మరియు సెంట్రల్ బ్రోకర్‌ను అమలు చేయడానికి ఒక ప్రత్యామ్నాయం ØMQని ఉపయోగించడం.


You should probably focus on the particular message pattern that you need to implement.

మీరు అమలు చేయవలసిన నిర్దిష్ట సందేశ నమూనాపై మీరు దృష్టి పెట్టాలి.


If you are using messages as simply a lightweight and load-balanced form of RPC.

మీరు సందేశాలను తేలికైన మరియు లోడ్-బ్యాలెన్స్డ్ RPC రూపంగా ఉపయోగిస్తుంటే.


Listing 8–3 shows some of the patterns that can be supported when message queues are used.

జాబితా 8–3 సందేశ క్యూలను ఉపయోగించినప్పుడు మద్దతు ఇవ్వగల కొన్ని నమూనాలను చూపుతుంది.