რატომ შეიძლება C სტრუქტურამ ცუდი SOCKS მოთხოვნა შექმნას
შეამოწმეთ ველების მკაფიო სიგანეები, ბაიტების რიგი და ნაკადური I/O იმის ნაცვლად, რომ კომპილატორის განლაგება ქსელურ ფორმატად მიიჩნიოთ.
სწორი პროქსის მისამართი ხელით დაწერილ SOCKS შეტყობინებას სწორს არ ხდის. C ან C++ სტრუქტურის გაგზავნამ შეიძლება გაგზავნოს შევსება ან ჰოსტის რიგის მთელი რიცხვები, რომლებიც პროტოკოლს არასდროს მოუთხოვია.
SOCKS5 დომენური სახელის CONNECT მოთხოვნისთვის, მეთოდის მოლაპარაკებისა და ნებისმიერი არჩეული ავთენტიფიკაციის შემდეგ ეს თანმიმდევრობა მკაფიოდ სერიალიზეთ:
- ვერსია, ბრძანება, დაცული ბაიტი და მისამართის ტიპი
- დომენის სიგრძე და დომენის ბაიტები
- ორბაიტიანი დანიშნულების პორტი ქსელური ბაიტების რიგში
მისამართების სიგრძეები დამოკიდებულია SOCKS ვერსიაზე და მისამართის ტიპზე. ფიქსირებული სიგანის რიცხვით ველებს სჭირდებათ მათი განსაზღვრული წარმოდგენა; დომენურ სტრიქონებს აქვთ საკუთარი სიგრძის კოდირება. C სტრიქონის დამამთავრებელი არ არის ზოგადი მითითება ქსელურ შეტყობინებაზე ნულის დასამატებლად.
| იმპლემენტაციის მოკლე გზა | შესამოწმებელი პრობლემა |
|---|---|
| 32-ბიტიანი მნიშვნელობის მინიჭება 8-ბიტიანი მაჩვენებლის მეშვეობით | ის არ გამოაქვს ოთხივე ბაიტი |
| ბუფერის მსხვილ მთელ რიცხვის მაჩვენებლად გარდაქმნა | გასწორება და ბაიტების რიგი კვლავ უნდა დამუშავდეს |
| ვივარაუდოთ, რომ ერთი წაკითხვა ან ჩაწერა ერთი შეტყობინებაა | TCP-ს შეუძლია გადასცეს პროტოკოლის თანმიმდევრობის მხოლოდ ნაწილი |
შეადარეთ თითოეული ველი განზრახ დანიშნულებას და დაამუშავეთ ნაწილობრივი I/O. ორი ბაიტის მიღება არ ამტკიცებს, რომ მთელი პასუხი ჩამოვიდა. ამ საზღვრების შემოწმებამ შეიძლება განასხვავოს დამახინჯებული მოთხოვნა სერვერისგან, რომელიც უარყოფს სწორად აღწერილ კავშირს.