Direct Connect ( DC ) เป็นโปรโตคอลการแชร์ไฟล์แบบ Peer-to-Peer ไคล เอนต์ Direct Connect จะเชื่อมต่อกับฮับ ส่วนกลาง และสามารถดาวน์โหลดไฟล์จากกันและกันได้โดยตรง Advanced Direct Connect อาจถือได้ว่าเป็นโปรโตคอลที่พัฒนาต่อยอดมาจาก Direct Connect

ฮับจะแสดงรายชื่อลูกค้าหรือผู้ใช้ที่เชื่อมต่ออยู่ ผู้ใช้สามารถค้นหาไฟล์และดาวน์โหลดจากลูกค้ารายอื่น รวมถึงสนทนากับผู้ใช้รายอื่นได้

NeoModus ก่อตั้งขึ้นโดย Jon Hess ในเดือนพฤศจิกายน พ.ศ. 2542 ขณะที่เขายังเรียนอยู่มัธยมปลาย โดย ได้รับเงินทุนจาก แอดแวร์ "Direct Connect" ^{[ 1 ]}

โปรแกรมไคลเอ็นต์จากผู้พัฒนาภายนอกตัวแรกมีชื่อว่า "DClite" ซึ่งไม่รองรับการแชร์ไฟล์ตามโปรโตคอลอย่างเต็มที่ Hess ได้ออกเวอร์ชันใหม่ของ Direct Connect ซึ่งต้องการเพียงรหัสเข้ารหัส แบบง่าย ในการเริ่มต้นการเชื่อมต่อ ทำให้ไคลเอ็นต์จากผู้พัฒนาภายนอกไม่สามารถใช้งานได้ ต่อมา รหัสเข้ารหัสถูกถอดรหัสได้ และผู้เขียน DClite ได้ออกเวอร์ชันใหม่ที่เข้ากันได้กับซอฟต์แวร์ใหม่จาก NeoModus หลังจากนั้นไม่นาน DClite ก็ถูกเขียนใหม่เป็น Open Direct Connect โดยมีจุดประสงค์เพื่อให้มีอินเทอร์เฟซผู้ใช้แบบ MDI และใช้ปลั๊กอินสำหรับโปรโตคอลการแชร์ไฟล์ (คล้ายกับMLDonkey ) Open Direct Connect ก็ไม่รองรับการแชร์ไฟล์ตามโปรโตคอลอย่างสมบูรณ์เช่นกัน แต่เวอร์ชันที่เขียนด้วยภาษา Javaนั้นรองรับ ต่อมา ไคลเอ็นต์อื่นๆ เช่น DCTC (Direct Connect Text Client) และDC++ก็ได้รับความนิยมมากขึ้น

เอกสาร DCDev ^{[ 2 ]}มีการอภิปรายเกี่ยวกับการเปลี่ยนแปลงโปรโตคอลสำหรับการพัฒนา DC ในช่วงปี พ.ศ. 2546–2548

โปรโตคอล Direct Connect เป็นโปรโตคอลคอมพิวเตอร์แบบข้อความ ซึ่งคำสั่งและข้อมูลจะถูกส่งในรูปแบบข้อความธรรมดาโดยไม่มีการเข้ารหัสในซอฟต์แวร์ NeoModus ดั้งเดิม ( การเข้ารหัสมีให้ใช้งานเป็นส่วนขยายของโปรโตคอล) ไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์กลางที่ทำหน้าที่เป็น "ฮับ" ฮับนี้ให้บริการค้นหาเนื้อหาและอนุญาตให้ไคลเอนต์เจรจาการเชื่อมต่อโดยตรงระหว่างกันเพื่อถ่ายโอนเนื้อหา เนื่องจากฮับกลางนี้จัดการเฉพาะข้อมูลเมตาเท่านั้น จึงไม่ต้องการแบนด์วิดท์มากเท่ากับกรณีที่ฮับให้บริการเนื้อหาเองด้วย จากการประมาณการพบว่าการจัดการผู้ใช้ 1,000 รายจะต้องใช้แบนด์วิดท์ประมาณ 2.5 เมกะบิตต่อวินาที^{[ 3 ]}

ไม่มีข้อกำหนดอย่างเป็นทางการของโปรโตคอล ซึ่งหมายความว่าไคลเอนต์และฮับทุกตัว (นอกเหนือจากไคลเอนต์และฮับ NeoModus ดั้งเดิม) ถูกบังคับให้ต้องวิเคราะห์ข้อมูลย้อนกลับ ดังนั้น ข้อกำหนดโปรโตคอลใดๆ ที่บทความนี้อาจอ้างถึงจึงมีแนวโน้มที่จะไม่ถูกต้องและ/หรือไม่สมบูรณ์^{[ 4 ]}

ลักษณะการทำงานแบบไคลเอนต์-เซิร์ฟเวอร์ (รวมถึงแบบไคลเอนต์-ไคลเอนต์ ที่ไคลเอนต์ตัวหนึ่งทำหน้าที่เป็น "เซิร์ฟเวอร์") ของโปรโตคอลนี้กำหนดว่าเซิร์ฟเวอร์จะเป็นฝ่ายตอบสนองก่อนเมื่อมีการเชื่อมต่อเกิดขึ้น ตัวอย่างเช่น เมื่อไคลเอนต์เชื่อมต่อกับซ็อกเก็ต ของฮับ ฮับ จะเป็นฝ่ายตอบสนองต่อไคลเอนต์ก่อน

โปรโตคอลนี้ไม่มีการกำหนดการเข้ารหัสอักขระ เริ่มต้น สำหรับไคลเอนต์หรือฮับ ไคลเอนต์และฮับดั้งเดิมใช้ การเข้ารหัส ASCIIแทนที่จะเป็นการเข้ารหัสของระบบปฏิบัติการซึ่งช่วยให้สามารถเปลี่ยนไปใช้ การเข้ารหัส UTF-8ในซอฟต์แวร์รุ่นใหม่ได้

พอร์ต 411 เป็นพอร์ตเริ่มต้นสำหรับฮับ และพอร์ต 412 สำหรับการเชื่อมต่อระหว่างไคลเอ็นต์ หากพอร์ตใดพอร์ตหนึ่งถูกใช้งานอยู่แล้ว หมายเลขพอร์ตจะเพิ่มขึ้นเรื่อยๆ จนกว่าจะพบหมายเลขพอร์ตว่างที่สามารถใช้งานได้ ตัวอย่างเช่น หากพอร์ต 411, 412 และ 413 ถูกใช้งานอยู่แล้ว พอร์ต 414 จะถูกใช้งานแทน

ที่อยู่ฮับมีรูปแบบดังนี้: dchub://example.com[:411] โดยที่ 411 เป็นพอร์ตที่ไม่บังคับ

ไม่มีระบบการระบุตัวตนระดับโลก แต่ผู้ใช้จะถูกระบุตัวตนด้วยชื่อเล่นตามแต่ละศูนย์กลาง

คำขอขาเข้าสำหรับการเชื่อมต่อระหว่างไคลเอ็นต์ไม่สามารถเชื่อมโยงกับการเชื่อมต่อจริงได้^{[ 5 ]}

ผลการค้นหาไม่สามารถเชื่อมโยงกับการค้นหาเฉพาะเจาะจงได้^{[ 6 ]}

โปรโตคอลนี้รองรับความสามารถในการเตะหรือย้าย (เปลี่ยนเส้นทาง) ผู้ใช้ไปยังฮับอื่น หากผู้ใช้ถูกเตะ ฮับไม่จำเป็นต้องให้เหตุผลเฉพาะเจาะจงแก่ผู้ใช้นั้น และไม่มีข้อจำกัดว่าผู้ใช้จะถูกเปลี่ยนเส้นทางไปที่ใด อย่างไรก็ตาม หากไคลเอ็นต์อื่นที่มีอำนาจสั่งให้ฮับเตะ ไคลเอ็นต์นั้นอาจส่งข้อความแจ้งเตือนก่อนที่จะดำเนินการ การเปลี่ยนเส้นทางผู้ใช้จะต้องมีเหตุผลประกอบ ไม่มีสิ่งที่เทียบเท่ากับHTTP referer

ฮับอาจส่งคำสั่งผู้ใช้ไปยังไคลเอ็นต์ คำสั่งเหล่านี้เป็นเพียงคำสั่งโปรโตคอลดิบ และส่วนใหญ่ใช้เพื่อทำให้งานเฉพาะอย่างง่ายขึ้น ตัวอย่างเช่น ฮับไม่สามารถส่งคำสั่งผู้ใช้ที่จะกระตุ้นให้เบราว์เซอร์เริ่มต้นเข้าชมเว็บไซต์ได้ อย่างไรก็ตาม ฮับสามารถเพิ่มคำสั่ง "+rules" (โดยที่ '+' บ่งบอกให้ฮับทราบว่าเป็นคำสั่ง ซึ่งอาจแตกต่างกันไป) เพื่อแสดงกฎของฮับได้

ส่วนที่เป็นการสื่อสารระหว่างบุคคล (peer-to-peer) ของโปรโตคอลนี้ใช้แนวคิดของ "สล็อต" (คล้ายกับจำนวนตำแหน่งงานว่าง) สล็อตเหล่านี้บ่งบอกถึงจำนวนคนที่ได้รับอนุญาตให้ดาวน์โหลดจากผู้ใช้รายใดรายหนึ่งได้ในเวลาใดเวลาหนึ่ง และถูกควบคุมโดยฝั่งไคลเอนต์

ในการเชื่อมต่อระหว่างไคลเอ็นต์ด้วยกันเอง ทั้งสองฝ่ายจะสร้างหมายเลขสุ่มเพื่อพิจารณาว่าใครควรได้รับอนุญาตให้ดาวน์โหลดก่อน และไคลเอ็นต์ที่มีหมายเลขมากกว่าจะเป็นผู้ชนะ

การรับส่งข้อมูลดาวน์โหลดและการเชื่อมต่อกับฮับต้องใช้โปรโตคอล TCPในขณะที่การค้นหาแบบแอคทีฟใช้โปรโตคอล UDP

ผู้ใช้สามารถอยู่ในโหมดได้สองแบบ คือ โหมด "แอคทีฟ" หรือโหมด "พาสซีฟ" ไคลเอนต์ที่ใช้โหมดแอคทีฟสามารถดาวน์โหลดจากผู้ใช้รายอื่นในเครือข่ายได้ ในขณะที่ไคลเอนต์ที่ใช้โหมดพาสซีฟสามารถดาวน์โหลดได้จากผู้ใช้แอคทีฟเท่านั้น ใน NeoModus Direct Connect ผู้ใช้โหมดพาสซีฟจะได้รับผลการค้นหาจากผู้ใช้โหมดพาสซีฟรายอื่น แต่จะไม่สามารถดาวน์โหลดอะไรได้ ในDC++ผู้ใช้จะไม่ได้รับผลการค้นหาเหล่านั้น ใน NeoModus Direct Connect ผู้ใช้ทุกคนจะได้รับผลการค้นหาอย่างมากที่สุดห้ารายการต่อการค้นหาหนึ่งครั้ง หากผู้ใช้ทำการค้นหาแล้ว DC++ จะตอบกลับด้วยผลการค้นหา 10 รายการเมื่อผู้ใช้อยู่ในโหมดแอคทีฟ และ 5 รายการเมื่อผู้ใช้อยู่ในโหมดพาสซีฟ ไคลเอนต์แบบพาสซีฟจะได้รับผลการค้นหาผ่านฮับ ในขณะที่ไคลเอนต์แบบแอคทีฟจะได้รับผลลัพธ์โดยตรง

ตัวคั่นโปรโตคอลคือ "$", "|" และU+0020 SPACE  โปรโตคอลมี ลำดับการหลีกเลี่ยงสำหรับตัวคั่นเหล่านี้ (และอีกไม่กี่ตัวคั่น) และซอฟต์แวร์ส่วนใหญ่ใช้ลำดับการเข้าสู่ระบบ (Lock to Key) อย่างถูกต้อง ด้วยเหตุผลบางประการ นักพัฒนา DC++ เพิกเฉย ต่อลำดับการหลีกเลี่ยง นั้น และใช้ รูปแบบ HTMLแทนหากต้องการให้ผู้ใช้เห็นอักขระเหล่านี้

ยังคงมีความสนใจอย่างต่อเนื่องในคุณสมบัติต่างๆ เช่น การให้คะแนนและชุดภาษา ผู้เขียน DC++ ยังเสนอโปรโตคอล Direct Connect ทดแทนโดยสมบูรณ์ที่เรียกว่า ADC หรือเรียกอย่างไม่เป็นทางการว่า Advanced Direct Connect ADC ใช้โทโพโลยีเครือข่ายแนวคิด และคำศัพท์เดียวกันกับโปรโตคอลดั้งเดิม^{[ 7 ]}

ตัวอย่างหนึ่งของฟีเจอร์เพิ่มเติมในโปรโตคอลนี้ เมื่อเปรียบเทียบกับโปรโตคอลดั้งเดิม คือการกระจายการเข้ารหัสแฮชแบบTiger-Tree Hashingของไฟล์ที่แชร์ (TTH) ข้อดีของฟีเจอร์นี้ ได้แก่ การตรวจสอบว่าไฟล์ถูกดาวน์โหลดอย่างถูกต้อง และความสามารถในการค้นหาไฟล์โดยไม่ขึ้นอยู่กับชื่อไฟล์

เนื่องจากโปรโตคอลอนุญาตให้ฮับเปลี่ยนเส้นทางผู้ใช้ไปยังฮับ อื่น ฮับที่เป็นอันตรายจึงเปลี่ยนเส้นทางผู้ใช้ไปยังสถานที่อื่นที่ไม่ใช่ฮับ Direct Connect จริง ทำให้เกิด การโจมตี แบบปฏิเสธการให้บริการแบบกระจาย (Distributed Denial of Service ) ฮับอาจเปลี่ยนแปลงIPในการเชื่อมต่อระหว่างไคลเอ็นต์ ซึ่งชี้ไปยังเหยื่อที่เป็นไปได้^{[ 8 ] [ 9 ] [ 10 ]}

ช่องโหว่ CTM ปรากฏขึ้นในช่วงปี 2549–2550 ซึ่งในช่วงเวลานั้นเครือข่าย Direct Connect ทั้งหมดได้รับผลกระทบจากการโจมตี DDoS ^{[ 11 ] [ 12 ]}สถานการณ์ดังกล่าวทำให้ผู้พัฒนาต้องให้ความสำคัญกับประเด็นด้านความปลอดภัยมากขึ้น^{[ 13 ]}

ณ เดือนกุมภาพันธ์ พ.ศ. 2552 ^{[ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 12 ]} ได้มีการเสนอ ส่วนขยายสำหรับไคลเอนต์เพื่อให้ฝ่ายที่ถูกโจมตีสามารถค้นหาฮับที่ส่งผู้ใช้ที่เชื่อมต่อได้

มูลนิธิเครือข่ายเชื่อมต่อโดยตรง (DCNF) เป็นองค์กรไม่แสวงหาผลกำไรที่จดทะเบียนในประเทศสวีเดน โดยมีเป้าหมายเพื่อปรับปรุงเครือข่าย DC ด้วยการปรับปรุงซอฟต์แวร์ โปรโตคอล และบริการอื่นๆ ในเครือข่าย^{[ 18 ]}

DCNF รวบรวมรายชื่อบทความ เอกสาร และเอกสารอื่นๆ ที่เกี่ยวข้องกับ DC ^{[ 19 ]}

• การเปรียบเทียบซอฟต์แวร์ Direct Connect

• วิกิโปรโตคอล NMDC (สำเนา) เก็บถาวรเมื่อ 2022-04-08 ที่Wayback Machine
• เอกสารโปรโตคอล NMDC
• โปรโตคอล NMDC