ଦୁଇଟି ପ୍ରକ୍ସି ଗୋଟିଏ ଫାଇଲ୍କୁ ଶୀଘ୍ର ଡାଉନଲୋଡ୍ କରିପାରିବ କି?
ଅନେକ ସଂଯୋଗର ବଣ୍ଟନ ଏବଂ ଗୋଟିଏ ଡାଉନଲୋଡ୍ ପାଇଁ ଏକାଧିକ ନେଟୱର୍କ ପଥର ମିଶ୍ରଣକୁ ଅଲଗା କରିବା।
ଦୁଇଟି ପ୍ରକ୍ସି ଏକ୍ଜିଟ୍, ପ୍ରତ୍ୟେକରେ ଅତିରିକ୍ତ ବ୍ୟାଣ୍ଡୱିଡଥ୍ ଅଛି, ଡାଉନଲୋଡ୍ର ଗତି ଦୁଇଗୁଣ କରିବାର ସହଜ ଉପାୟ ପରି ଦେଖାଯାଏ। ସାଧାରଣ ପ୍ରକ୍ସି ପୁଲ୍ ଏପରି କାମ କରେ ନାହିଁ।
କ୍ଲାଏଣ୍ଟ ଏକ ମନୋନୀତ ପ୍ରକ୍ସି ମାଧ୍ୟମରେ ସଂଯୋଗ ଖୋଲେ। ସେହି ପ୍ରକ୍ସି ପରବର୍ତ୍ତୀ ସଂଯୋଗ ଖୋଲେ। ପ୍ରକ୍ସି ତାଲିକାରୁ ଅନ୍ୟ ଠିକଣା ପୁଲ୍ରେ ଯୋଡ଼ିଲେ ଭବିଷ୍ୟତର ସଂଯୋଗକୁ ଆଉ ଏକ ବିକଳ୍ପ ମିଳେ; ଏହା ଦ୍ୱିତୀୟ ପ୍ରକ୍ସିକୁ ପୂର୍ବରୁ ଚାଲୁଥିବା ବାଇଟ୍ ଷ୍ଟ୍ରିମ୍ରେ ଯୋଡ଼େ ନାହିଁ।
ସାଧାରଣ ସଂଯୋଗ-ଆଧାରିତ ମଲ୍ଟି-ୱାନ୍ ସନ୍ତୁଳନର ମଧ୍ୟ ସମାନ ସୀମା ଅଛି। ଏହା ବିଭିନ୍ନ ସଂଯୋଗକୁ ଲିଙ୍କ୍ ମଧ୍ୟରେ ବିସ୍ତାର କରିପାରେ, ଯାହା ସମଗ୍ର କ୍ଷମତା ବଢ଼ାଏ କିମ୍ବା ପ୍ରତିଯୋଗିତା କମାଏ। ଅନ୍ୟ କୌଣସି ବ୍ୟବସ୍ଥା ସ୍ପଷ୍ଟଭାବେ ଏକାଧିକ ପଥ ନଦେଲେ ଏକ ସଂଯୋଗ ଏକ ସଂଯୋଗ ହୋଇ ରହେ।
ଯେତେବେଳେ ସମାନ୍ତରାଳ ଡାଉନଲୋଡ୍ ଅନ୍ୟ କଥା
କ୍ଲାଏଣ୍ଟ ଏକ ଫାଇଲ୍ର ବିଭିନ୍ନ ପରିସର ଅଲଗା ସଂଯୋଗରେ ମାଗି ସ୍ଥାନୀୟଭାବେ ଯୋଡ଼ିପାରେ। କ୍ଲାଏଣ୍ଟ ଏହି ବ୍ୟବସ୍ଥାକୁ ସମର୍ଥନ କଲେ ଏବଂ ସର୍ଭର ଅନୁରୋଧକୁ ଅନୁମତି ଦେଲେ ଏହା ଏକରୁ ଅଧିକ ପଥ ବ୍ୟବହାର କରିପାରେ।
ଏହା କିଛି ଶର୍ତ୍ତ ଆଣେ: ପରିସରଗୁଡ଼ିକ ଏକ ସମାନ ଉପସ୍ଥାପନା ବର୍ଣ୍ଣନା କରିବା ଆବଶ୍ୟକ, ସର୍ଭରର ଉତ୍ତର ମଗାଯାଇଥିବା ଅଫସେଟ ସହିତ ମେଳ ଖାଇବା ଉଚିତ, ଏବଂ ବସ୍ତୁର ପରିବର୍ତ୍ତନ ମିଶ୍ରିତ ଫାଇଲ୍ ସୃଷ୍ଟି କରିବା ଉଚିତ ନୁହେଁ। ପ୍ରମାଣୀକରଣ, ସର୍ଭରର ସୀମା ଏବଂ ପ୍ରତ୍ୟେକ ଏକ୍ଜିଟର ନୀତି ମଧ୍ୟ ସମାନ୍ତରାଳ ପରିସର ଅନୁରୋଧକୁ ଅନୁପଯୁକ୍ତ କରିପାରେ। ଦଶଟି ସମ୍ପୂର୍ଣ୍ଣ ଡାଉନଲୋଡ୍ ଏକ ଡାଉନଲୋଡ୍ର ଦଶଟି ଖଣ୍ଡ ନୁହେଁ।
କ୍ଲାଏଣ୍ଟ ପର୍ଯ୍ୟନ୍ତ ଅନ୍ତିମ ପଥ ଏବେ ମଧ୍ୟ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। ଅନେକ ଦ୍ରୁତ ଏକ୍ଜିଟ୍ ଏକ ଭର୍ତ୍ତି ଆକ୍ସେସ୍ ଲିଙ୍କ୍ ମାଧ୍ୟମରେ ସେହି ଲିଙ୍କ୍ ବହନ କରିପାରୁଥିବା ଠାରୁ ଅଧିକ ଡାଟା ପଠାଇପାରିବ ନାହିଁ।
ମଲ୍ଟିପାଥ୍କୁ ପ୍ରକୃତ ସମର୍ଥନ ଦରକାର
Multipath TCP ଏକ ସ୍ପଷ୍ଟ ପରିବହନ ବ୍ୟବସ୍ଥା ଯାହା ଏହାର ପ୍ରାନ୍ତବିନ୍ଦୁ ଏବଂ ନେଟୱର୍କ ବ୍ୟବସ୍ଥା ସମର୍ଥନ କଲେ ଏକାଧିକ ଉପ-ଷ୍ଟ୍ରିମ୍ ବ୍ୟବହାର କରି ସଂଯୋଗ ବହନ କରିପାରେ। କେବଳ ଦୁଇଟି ଅସମ୍ପୃକ୍ତ HTTP କିମ୍ବା SOCKS ପ୍ରକ୍ସି ତାଲିକାଭୁକ୍ତ କରିବା ଦ୍ୱାରା ଏହା ସକ୍ରିୟ ହୁଏ ନାହିଁ।
ମନ୍ଥର ସ୍ଥାନାନ୍ତର ପାଇଁ ପ୍ରଥମେ ନିର୍ଣ୍ଣୟ କରନ୍ତୁ ସୀମା କ୍ଲାଏଣ୍ଟ ଲିଙ୍କ୍ରେ ଅଛି, ପ୍ରକ୍ସିରେ ଅଛି, ପରବର୍ତ୍ତୀ ପଥରେ ଅଛି କି ଗନ୍ତବ୍ୟରେ। ପୁଲ୍ ସଂଯୋଗ ବଣ୍ଟନ ପାଇଁ ଉପଯୋଗୀ। ଏକ ଫାଇଲ୍ର ଗତି ଦୁଇଗୁଣ ହେବା ଦାବିକୁ ନିଜସ୍ୱ ବ୍ୟବସ୍ଥା ଏବଂ ପ୍ରମାଣ ଦରକାର କରୁଥିବା ଏକ ଅଲଗା ବୈଶିଷ୍ଟ୍ୟ ଭାବରେ ଦେଖନ୍ତୁ।