Python SOCKS ಓದುವ ಲೂಪ್‌ನಲ್ಲಿ EOF ನಿರ್ವಹಿಸಿ

ಒಂದು ಲೂಪ್ SOCKS ಪ್ರತಿಕ್ರಿಯೆಯ ಎಂಟು ಬೈಟ್‌ಗಳನ್ನು ಬಯಸುತ್ತದೆ. ಅದು ಮೂರು ಪಡೆದಿದೆ. ಮುಂದಿನ ಓದು b'' ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಲೂಪ್ ಅದನ್ನು ಸೇರಿಸುತ್ತದೆ, ಉದ್ದವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಶಾಶ್ವತವಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಇದು EOF ನಿರ್ವಹಣೆಯ ದೋಷ, ಹೆಚ್ಚು ಉದ್ದದ ಟೈಮೌಟ್ ಬೇಕಾದ ನಿಧಾನ ಪ್ರಾಕ್ಸಿ ಅಲ್ಲ. ಸಾಮಾನ್ಯ ಸ್ಟ್ರೀಮ್-ಸಾಕೆಟ್ ಸ್ವೀಕಾರದಲ್ಲಿ, ಖಾಲಿ ಬೈಟ್ ಸ್ಟ್ರಿಂಗ್ ಎಂದರೆ ಸಹವರ್ತಿ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿದೆ. ಉಳಿದ ಐದು ಬೈಟ್‌ಗಳು ಆ ಸಂಪರ್ಕದಲ್ಲಿ ಬರುವುದಿಲ್ಲ.

ನಿಖರ-ಓದುವ ಸಹಾಯಕಕ್ಕೆ ಮೂರು ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳು ಬೇಕು: ಖಾಲಿಯಲ್ಲದ ತುಣುಕುಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ಅಗತ್ಯವಿರುವ ಉದ್ದಕ್ಕಿಂತ ಮೊದಲು EOF ನಲ್ಲಿ ವಿಫಲವಾಗುವುದು, ಮತ್ತು ಟೈಮೌಟ್ ಅಥವಾ ಇತರ ಸಾಕೆಟ್ ದೋಷವನ್ನು ರವಾನಿಸುವುದು. ಆ ಪ್ರಕರಣಗಳು ಒಂದೇ ಸಾಮಾನ್ಯ ಮರುಪ್ರಯತ್ನ ಲೂಪ್‌ನಲ್ಲಿ ವಿಲೀನವಾಗಬಾರದು.

ಕಾರ್ಯಾಚರಣೆಗೆ ಮೊದಲು ಸಾಕೆಟ್‌ನ ಉದ್ದೇಶಿತ ಟೈಮೌಟ್ ಹೊಂದಿಸಿ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಪ್ರೋಟೋಕಾಲ್ ಸೂಚಿಸುವ ಕ್ಷೇತ್ರ ಉದ್ದಗಳನ್ನು ಓದಿ. ಒಂದೇ ಸ್ವೀಕಾರವು ಪ್ರತಿಕ್ರಿಯೆಯ ಒಂದು ಭಾಗವನ್ನು ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಬಹುದು. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ದೊಡ್ಡ ಸ್ಥಿರ ಬಫರ್ ಕೇಳುವುದು ಪ್ರತಿ SOCKS ವಿಳಾಸವೂ ಆ ಉದ್ದವಾಗುವಂತೆ ಮಾಡುವುದಿಲ್ಲ.

ಹಳೆಯ MSG_WAITALL ಸ್ನಿಪೆಟ್ ಅನ್ನು ಅದರ ಮೂಲಕ್ಕೆ ಅಂಟಿಸಿ ಅದು EOF, ಸಿಗ್ನಲ್‌ಗಳು ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವರ್ತನೆಯನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ ಅವಲಂಬನೆಯನ್ನು ಸರಿಪಡಿಸಬೇಡಿ. ನಿರ್ವಹಿಸಲಾದ ಅನುಷ್ಠಾನದ ಬೆಂಬಲಿತ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಆದ್ಯತೆ ನೀಡಿ, ಅಥವಾ ಪಾರ್ಸರ್ ನಿಮ್ಮ ಕೋಡ್ ಆಗಿದ್ದಾಗ ಸಹಾಯಕದ ಒಪ್ಪಂದವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಜಾರಿಗೊಳಿಸಿ.

ಎಷ್ಟು ಬೈಟ್‌ಗಳು ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟವು ಮತ್ತು ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟವು ಎಂಬುದನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ, ರುಜುವಾತು ಪೇಲೋಡ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡದೆ. “ಎಂಟು ಪ್ರತಿಕ್ರಿಯೆ ಬೈಟ್‌ಗಳಲ್ಲಿ ಮೂರರ ನಂತರ EOF” ಮುರಿದ ವಿನಿಮಯವನ್ನು “ಪ್ರಾಕ್ಸಿ ಮತ್ತೆ ನೇತಾಡುತ್ತಿದೆ” ಗಿಂತ ಬಹಳ ಚೆನ್ನಾಗಿ ವಿವರಿಸುತ್ತದೆ.