PHP cURL ਲਿਖਣ ਕਾਲਬੈਕਾਂ ਨੂੰ ਸੰਭਾਲੇ ਗਏ ਬਾਈਟਾਂ ਦੀ ਗਿਣਤੀ ਵਾਪਸ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ
ਪ੍ਰੌਕਸੀ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਟੁਕੜੇ ਵਰਤਦੇ ਸਮੇਂ ਬਾਈਟ-ਗਿਣਤੀ ਦੇ ਸਮਝੌਤੇ ਦੀ ਪਾਲਣਾ ਕਰੋ ਅਤੇ ਸਥਾਨਕ ਲਿਖਣ ਅਸਫਲਤਾ ਨੂੰ ਅਸਫਲ ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਖਰਾ ਕਰੋ।
ਪ੍ਰੌਕਸੀ ਡੇਟਾ ਪਹੁੰਚਾਉਂਦੀ ਹੈ। ਤੁਹਾਡਾ ਲਿਖਣ ਕਾਲਬੈਕ ਗਲਤ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਫਿਰ 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 ਦਸਤਾਵੇਜ਼ ਜਾਂ ਸੇਵਾ ਤੋਂ ਇੱਕ ਸੁਨੇਹਾ ਹੋਵੇ।
ਇਨਕ੍ਰਿਮੈਂਟਲ ਪਾਰਸਿੰਗ ਲਈ ਕਾਲਬੈਕਾਂ ਵਿਚਕਾਰ ਆਪਣੀ ਸਥਿਤੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਦੇ ਉਲਟ, ਪੂਰਾ ਹੋਣ ਤੱਕ ਹਰ ਟੁਕੜਾ ਇਕੱਠਾ ਕਰਨਾ ਛੋਟੀ ਸੀਮਤ ਪ੍ਰਤੀਕਿਰਿਆ ਲਈ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਵੱਡੀ ਜਾਂ ਬੇਅੰਤ ਸਟ੍ਰੀਮ ਲਈ ਮੈਮਰੀ ਨੀਤੀ ਨਹੀਂ।
ਟ੍ਰਾਂਸਫਰ ਦਾ ਨਤੀਜਾ ਅਤੇ ਕਾਲਬੈਕ ਅਸਫਲਤਾ ਦਾ ਸਬੂਤ ਰੱਖੋ। ਵੈਧ ਪ੍ਰੌਕਸੀ ਮਾਰਗ ਸਥਾਪਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਥਾਨਕ ਡਿਸਕ ਗਲਤੀ ਜਾਂ ਪਾਰਸਰ ਰੁਕ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਬਾਅਦ ਰੁਕਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਉਸ ਜਾਣ-ਬੁੱਝ ਕੇ ਕਾਲਬੈਕ ਰੋਕ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਚਿੰਨ੍ਹਿਤ ਕਰੋ। ਪ੍ਰੌਕਸੀ ਪਤਾ ਬਦਲਣ ਨਾਲ ਡੇਟਾ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਚੁੱਕੇ ਸਿੰਕ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।