پراکسی ڈیٹا پہنچاتی ہے۔ آپ کا رائٹ کال بیک غلط قدر واپس کرتا ہے۔ پھر libcurl رک جاتا ہے، اور ارد گرد کا کوڈ ایک اور “پراکسی ڈاؤن لوڈ ناکامی” رپورٹ کرتا ہے۔

کال بیک کو بتانا چاہیے کہ اس نے واقعی کتنے موصول شدہ بائٹس ہینڈل کیے۔ مختلف تعداد واپس کرنا ناکامی کی علامت ہے۔ جان بوجھ کر بلاک کرنے والے رائٹ ہدف کے لیے، ایک ٹکڑا ایسا ہو سکتا ہے:

curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_WRITEFUNCTION,
    function ($handle, $chunk) use ($sink) {
        $written = fwrite($sink, $chunk);
        return $written === false ? 0 : $written;
    }
);

یہ فرض کرتا ہے کہ موجودہ ایپلیکیشن کے پاس handle اور رائٹ ہدف ہے۔ ناکام یا مختصر رائٹ پورے ٹکڑے کے محفوظ ہونے کا خاموشی سے دعویٰ کرنے کے بجائے رک جاتی ہے۔ غیر بلاکنگ ہدف کو مناسب بفرنگ اور وقفہ/دوبارہ شروع کرنے کا ڈیزائن درکار ہوتا ہے؛ چھوٹا ٹکڑا یہ فراہم نہیں کرتا۔

بائٹس گنیں، دکھائے گئے حروف نہیں۔ ڈیٹا بائنری یا کثیر بائٹ متن کی ترتیب کا حصہ ہو سکتا ہے۔ ایک کال بیک لازمی نہیں کہ ایک سطر، ایک JSON دستاویز یا سروس سے ایک پیغام ہو۔

انکریمنٹل پارسنگ کو کال بیکس کے درمیان اپنی حالت درکار ہوتی ہے۔ اس کے برعکس، ہر ٹکڑے کو مکمل ہونے تک جمع کرنا چھوٹے محدود جواب کے لیے درست ہو سکتا ہے، مگر بڑے یا لامحدود اسٹریم کے لیے میموری پالیسی نہیں ہے۔

منتقلی کا نتیجہ اور کال بیک ناکامی کا ثبوت محفوظ رکھیں۔ درست پراکسی راستہ قائم ہونے کے بعد مقامی ڈسک خرابی یا پارسر کا رکنا واقع ہو سکتا ہے۔ اگر آپ کسی سابقہ کے بعد رکنا چاہتے ہیں تو اس جان بوجھ کر کال بیک روکنے کو الگ نشان زد کریں۔ پراکسی پتہ بدلنا ایسے ہدف کو ٹھیک نہیں کر سکتا جس نے ڈیٹا قبول کرنا بند کر دیا ہو۔

متعلقہ مضامین