ບໍ່ດົນມານີ້, ຂໍ້ຄວາມກ່ຽວກັບ Telegram ທີ່ດີ, ອ້າຍ Durov ມີຄວາມສະຫລາດແລະມີປະສົບການໃນການກໍ່ສ້າງລະບົບເຄືອຂ່າຍ, ແລະອື່ນໆ. ໄດ້ເລີ່ມຕົ້ນທີ່ຈະປາກົດຢູ່ໃນHabre. ໃນເວລາດຽວກັນ, ມີຄົນຈໍານວນຫນ້ອຍຫຼາຍໄດ້ immersed ຕົນເອງໃນອຸປະກອນດ້ານວິຊາການ - ຫຼາຍທີ່ສຸດ, ພວກເຂົາເຈົ້າໃຊ້ຂ້ອນຂ້າງງ່າຍດາຍ (ແລະຂ້ອນຂ້າງແຕກຕ່າງຈາກ MTProto) JSON-based Bot API, ແລະປົກກະຕິແລ້ວພຽງແຕ່ຍອມຮັບ. ກ່ຽວກັບສັດທາ ການຍ້ອງຍໍແລະ PR ທັງໝົດທີ່ໝູນອ້ອມຜູ້ສົ່ງຂ່າວ. ເກືອບຫນຶ່ງປີແລະເຄິ່ງຫນຶ່ງກ່ອນຫນ້ານີ້, ເພື່ອນຮ່ວມງານຂອງຂ້ອຍຢູ່ Eshelon NGO Vasily (ຫນ້າເສຍດາຍ, ບັນຊີຂອງລາວໃນHabréໄດ້ຖືກລຶບລ້າງພ້ອມກັບຮ່າງ) ເລີ່ມຂຽນລູກຄ້າ Telegram ຂອງຕົນເອງຕັ້ງແຕ່ຕົ້ນໃນ Perl, ແລະຕໍ່ມາຜູ້ຂຽນຂອງສາຍເຫຼົ່ານີ້ໄດ້ເຂົ້າຮ່ວມ. ເປັນຫຍັງ Perl, ບາງຄົນຈະຖາມທັນທີ? ເນື່ອງຈາກວ່າໂຄງການດັ່ງກ່າວມີຢູ່ໃນພາສາອື່ນແລ້ວ, ໃນຄວາມເປັນຈິງ, ນີ້ບໍ່ແມ່ນຈຸດ, ມັນອາດຈະເປັນພາສາອື່ນທີ່ບໍ່ມີ. ຫ້ອງສະຫມຸດພ້ອມແລ້ວ, ແລະຕາມຄວາມເຫມາະສົມຜູ້ຂຽນຕ້ອງໄປທັງຫມົດ ຈາກ scratch. ຍິ່ງໄປກວ່ານັ້ນ, ການເຂົ້າລະຫັດລັບແມ່ນເປັນເລື່ອງທີ່ຫນ້າເຊື່ອຖື, ແຕ່ຢືນຢັນ. ດ້ວຍຜະລິດຕະພັນທີ່ແນໃສ່ຄວາມປອດໄພ, ທ່ານບໍ່ສາມາດພຽງແຕ່ອີງໃສ່ຫ້ອງສະຫມຸດທີ່ກຽມພ້ອມຈາກຜູ້ຜະລິດແລະໄວ້ວາງໃຈມັນໂດຍຕາບອດ (ຢ່າງໃດກໍ່ຕາມ, ນີ້ແມ່ນຫົວຂໍ້ສໍາລັບພາກທີສອງ). ໃນປັດຈຸບັນ, ຫ້ອງສະຫມຸດເຮັດວຽກໄດ້ດີໃນລະດັບ "ສະເລ່ຍ" (ອະນຸຍາດໃຫ້ທ່ານເຮັດການຮ້ອງຂໍ API ໃດ).

ຢ່າງໃດກໍຕາມ, ຈະບໍ່ມີການເຂົ້າລະຫັດຫຼືຄະນິດສາດຫຼາຍໃນຊຸດຂອງຫົວຂໍ້ນີ້. ແຕ່ຈະມີລາຍລະອຽດດ້ານວິຊາການອື່ນໆຈໍານວນຫຼາຍແລະ crutches ຖາປັດຕະຍະ (ຍັງເປັນປະໂຫຍດສໍາລັບຜູ້ທີ່ຈະບໍ່ຂຽນຈາກ scratch, ແຕ່ຈະໃຊ້ຫ້ອງສະຫມຸດໃນພາສາໃດກໍ່ຕາມ). ດັ່ງນັ້ນ, ເປົ້າຫມາຍຕົ້ນຕໍແມ່ນເພື່ອພະຍາຍາມປະຕິບັດລູກຄ້າຈາກ scratch ອີງຕາມເອກະສານທາງການ. ນັ້ນແມ່ນ, ໃຫ້ສົມມຸດວ່າລະຫັດແຫຼ່ງຂອງລູກຄ້າຢ່າງເປັນທາງການຖືກປິດ (ອີກເທື່ອຫນຶ່ງ, ໃນພາກທີສອງພວກເຮົາຈະກວມເອົາລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບຫົວຂໍ້ຂອງຄວາມຈິງທີ່ວ່ານີ້ແມ່ນຄວາມຈິງ. ເກີດຂຶ້ນ ດັ່ງນັ້ນ), ແຕ່, ສໍາລັບຕົວຢ່າງ, ມີມາດຕະຖານເຊັ່ນ RFC - ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນລູກຄ້າຕາມເງື່ອນໄຂສະເພາະ, "ໂດຍບໍ່ມີການເບິ່ງ" ຢູ່ໃນລະຫັດແຫຼ່ງ, ບໍ່ວ່າຈະເປັນທາງການ (Telegram Desktop, ມືຖື), ຫຼື Telethon ທີ່ບໍ່ເປັນທາງການ?

ພາສາ:

• ເອກະສານ... ມັນມີຢູ່ບໍ? ມັນ​ເປັນ​ຄວາມ​ຈິງ​?..
• ບ່ອນທີ່ຈະເລີ່ມຕົ້ນເປັນນັກຂຽນຫນຸ່ມ?
• Binary serialization: TL (Type Language) ແລະຮູບແບບຂອງມັນ, ແລະຊັ້ນ, ແລະຫຼາຍຄໍາທີ່ຫນ້າຢ້ານອື່ນໆ
  • ລາຍລະອຽດສັ້ນໆຂອງຊຸດຍ່ອຍຂອງ syntax TL ສໍາລັບຜູ້ທີ່ບໍ່ຕ້ອງການອ່ານເອກະສານທີ່ເປັນທາງການ
  • vector, ເຊິ່ງບໍ່ເຄີຍປ່ອຍອອກມາ
  • ການປະຕິບັດ TL ທີ່ມີຢູ່ແລ້ວໃນລະຫັດ
  • ຂາດປະເພດໃນພາສາປະເພດ
  • ຮຸ່ນ. ຊັ້ນ
• MT Proto
  • ຊັ້ນການຂົນສົ່ງ
  • ກະແຈ, ຂໍ້ຄວາມ, ກອງປະຊຸມ, Diffie-Hellman
  • ຂໍ້ຄວາມ, msg_id, msg_seqno, ການຢືນຢັນ, pings ໃນທິດທາງທີ່ບໍ່ຖືກຕ້ອງແລະ idiosyncrasies ອື່ນໆ
    • RPC: ການຮ້ອງຂໍ, ຄໍາຕອບ, ຄວາມຜິດພາດ. ການຢືນຢັນ.
    • ການຕິດຢາເສບຕິດ: ສະຖານະພາບຂໍ້ຄວາມ
    • Pings ແລະເວລາ. ຄິວ.
    • ມັນຄວນຈະຖືກອອກແບບແນວໃດ?
• API?
• ຕິດ​ຕາມ​ຕອນ​ຕໍ່​ໄປ!

ເອກະສານ... ມັນມີຢູ່ບໍ? ມັນ​ເປັນ​ຄວາມ​ຈິງ​?..

ຊິ້ນສ່ວນຂອງບັນທຶກສໍາລັບບົດຄວາມນີ້ໄດ້ເລີ່ມຕົ້ນທີ່ຈະເກັບກໍາໃນລະດູຮ້ອນທີ່ຜ່ານມາ. ເວລາທັງຫມົດນີ້ຢູ່ໃນເວັບໄຊທ໌ທາງການ https://core.telegram.org ເອກະສານແມ່ນເປັນຂອງຊັ້ນ 23, i.e. ຕິດຢູ່ບ່ອນໃດບ່ອນໜຶ່ງໃນປີ 2014 (ຈື່ໄວ້ວ່າ, ບໍ່ມີຊ່ອງທາງໃນເມື່ອນັ້ນບໍ?). ແນ່ນອນ, ໃນທາງທິດສະດີ, ນີ້ຄວນຈະອະນຸຍາດໃຫ້ພວກເຮົາປະຕິບັດລູກຄ້າທີ່ມີຫນ້າທີ່ເຮັດວຽກໃນເວລານັ້ນໃນປີ 2014. ແຕ່ເຖິງແມ່ນວ່າຢູ່ໃນລັດນີ້, ເອກະສານແມ່ນ, ທໍາອິດ, ບໍ່ຄົບຖ້ວນ, ແລະອັນທີສອງ, ໃນສະຖານທີ່ທີ່ມັນກົງກັນຂ້າມກັບຕົວມັນເອງ. ພຽງແຕ່ຫຼາຍກວ່າຫນຶ່ງເດືອນກ່ອນຫນ້ານີ້, ໃນເດືອນກັນຍາ 2019, ມັນແມ່ນ ໂດຍບັງເອີນ ມັນໄດ້ຖືກຄົ້ນພົບວ່າມີການປັບປຸງຂະຫນາດໃຫຍ່ຂອງເອກະສານຢູ່ໃນເວັບໄຊທ໌, ສໍາລັບ Layer 105 ທີ່ຜ່ານມາຢ່າງສົມບູນ, ໂດຍສັງເກດວ່າໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງຕ້ອງໄດ້ຮັບການອ່ານອີກເທື່ອຫນຶ່ງ. ແທ້ຈິງແລ້ວ, ບົດຄວາມຫຼາຍສະບັບໄດ້ຖືກປັບປຸງ, ແຕ່ຫຼາຍໆຢ່າງຍັງຄົງບໍ່ປ່ຽນແປງ. ດັ່ງນັ້ນ, ເມື່ອອ່ານຄໍາວິຈານຂ້າງລຸ່ມນີ້ກ່ຽວກັບເອກະສານ, ທ່ານຄວນຈື່ໄວ້ວ່າບາງສິ່ງເຫຼົ່ານີ້ບໍ່ກ່ຽວຂ້ອງອີກຕໍ່ໄປ, ແຕ່ບາງອັນຍັງຂ້ອນຂ້າງ. ຫຼັງຈາກທີ່ທັງຫມົດ, 5 ປີໃນໂລກທີ່ທັນສະໄຫມບໍ່ພຽງແຕ່ເປັນເວລາດົນນານ, ແຕ່ ຫຼາຍ ຫຼາຍ. ນັບຕັ້ງແຕ່ເວລານັ້ນ (ໂດຍສະເພາະຖ້າທ່ານບໍ່ຄໍານຶງເຖິງສະຖານທີ່ geochat ທີ່ຖືກຍົກເລີກແລະຟື້ນຟູຕັ້ງແຕ່ນັ້ນມາ), ຈໍານວນຂອງວິທີການ API ໃນໂຄງການໄດ້ເພີ່ມຂຶ້ນຈາກຮ້ອຍຫາຫຼາຍກວ່າສອງຮ້ອຍຫ້າສິບ!

ບ່ອນທີ່ຈະເລີ່ມຕົ້ນເປັນນັກຂຽນຫນຸ່ມ?

ມັນບໍ່ສໍາຄັນວ່າທ່ານຈະຂຽນຈາກຈຸດເລີ່ມຕົ້ນຫຼືໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ຫ້ອງສະຫມຸດພ້ອມທີ່ຈະເຮັດເຊັ່ນ Telethon ສໍາລັບ Python ຫຼື Madeline ສໍາລັບ PHP, ໃນກໍລະນີໃດກໍ່ຕາມ, ທ່ານຈໍາເປັນຕ້ອງທໍາອິດ ລົງ​ທະ​ບຽນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​ - ໄດ້​ຮັບ​ຕົວ​ກໍາ​ນົດ​ການ​ api_id и api_hash (ຜູ້ທີ່ໄດ້ເຮັດວຽກກັບ VKontakte API ທັນທີເຂົ້າໃຈ) ໂດຍທີ່ເຄື່ອງແມ່ຂ່າຍຈະກໍານົດຄໍາຮ້ອງສະຫມັກ. ນີ້ ຈໍາ​ຕ້ອງ ເຮັດມັນສໍາລັບເຫດຜົນທາງກົດຫມາຍ, ແຕ່ພວກເຮົາຈະເວົ້າເພີ່ມເຕີມກ່ຽວກັບວ່າເປັນຫຍັງຜູ້ຂຽນຫ້ອງສະຫມຸດບໍ່ສາມາດເຜີຍແຜ່ມັນຢູ່ໃນພາກທີສອງ. ທ່ານອາດຈະພໍໃຈກັບຄ່າການທົດສອບ, ເຖິງແມ່ນວ່າພວກມັນມີຈໍາກັດຫຼາຍ - ຄວາມຈິງແລ້ວແມ່ນວ່າຕອນນີ້ທ່ານສາມາດລົງທະບຽນໄດ້ ພຽງ​ແຕ່​ຫນຶ່ງ​ app, ສະນັ້ນຢ່າຟ້າວເຂົ້າໄປໃນມັນ.

ໃນປັດຈຸບັນ, ຈາກມຸມເບິ່ງດ້ານວິຊາການ, ພວກເຮົາຄວນຈະສົນໃຈຄວາມຈິງທີ່ວ່າຫຼັງຈາກການລົງທະບຽນພວກເຮົາຄວນໄດ້ຮັບການແຈ້ງເຕືອນຈາກ Telegram ກ່ຽວກັບການປັບປຸງເອກະສານ, ໂປໂຕຄອນ, ແລະອື່ນໆ. ນັ້ນແມ່ນ, ຄົນເຮົາສາມາດສົມມຸດວ່າສະຖານທີ່ທີ່ມີ docks ໄດ້ຖືກປະຖິ້ມໄວ້ຢ່າງງ່າຍດາຍແລະສືບຕໍ່ເຮັດວຽກໂດຍສະເພາະກັບຜູ້ທີ່ເລີ່ມສ້າງລູກຄ້າ, ເພາະວ່າ. ມັນງ່າຍຂຶ້ນ. ແຕ່ບໍ່ມີ, ບໍ່ມີຫຍັງຄ້າຍຄືວ່າໄດ້ຖືກສັງເກດເຫັນ, ບໍ່ມີຂໍ້ມູນມາ.

ແລະຖ້າທ່ານຂຽນຈາກ scratch, ຫຼັງຈາກນັ້ນການນໍາໃຊ້ຕົວກໍານົດການທີ່ໄດ້ຮັບແມ່ນຕົວຈິງແລ້ວຍັງເປັນທາງຍາວໄກ. ເຖິງແມ່ນວ່າ https://core.telegram.org/ ແລະເວົ້າກ່ຽວກັບພວກມັນໃນການເລີ່ມຕົ້ນ, ໃນຄວາມເປັນຈິງ, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງປະຕິບັດ ອະນຸສັນຍາ MTProto - ແຕ່ຖ້າຫາກວ່າທ່ານເຊື່ອ ການຈັດວາງຕາມຮູບແບບ OSI ໃນຕອນທ້າຍຂອງຫນ້າສໍາລັບຄໍາອະທິບາຍທົ່ວໄປຂອງໂປໂຕຄອນ, ຫຼັງຈາກນັ້ນມັນໄຮ້ປະໂຫຍດ.

ໃນຄວາມເປັນຈິງ, ທັງກ່ອນແລະຫຼັງຈາກ MTProto, ໃນຫຼາຍລະດັບໃນເວລາດຽວກັນ (ຍ້ອນວ່າເຄືອຂ່າຍຕ່າງປະເທດທີ່ເຮັດວຽກຢູ່ໃນ OS kernel ເວົ້າວ່າ, ການລະເມີດຊັ້ນ), ຫົວຂໍ້ໃຫຍ່, ເຈັບປວດແລະຂີ້ຮ້າຍຈະໄດ້ຮັບໃນວິທີການ ...

Binary serialization: TL (Type Language) ແລະຮູບແບບຂອງມັນ, ແລະຊັ້ນ, ແລະຫຼາຍຄໍາທີ່ຫນ້າຢ້ານອື່ນໆ

ຫົວຂໍ້ນີ້, ໃນຄວາມເປັນຈິງ, ແມ່ນກຸນແຈສໍາລັບບັນຫາຂອງ Telegram. ແລະຈະມີຄໍາເວົ້າທີ່ຂີ້ຮ້າຍຫຼາຍຖ້າທ່ານພະຍາຍາມເຈາະເລິກມັນ.

ດັ່ງນັ້ນ, ນີ້ແມ່ນແຜນວາດ. ຖ້າ​ຫາກ​ວ່າ​ຄໍາ​ນີ້​ມາ​ເຖິງ​ຈິດ​ໃຈ​ຂອງ​ທ່ານ​, ເວົ້າ​ວ່າ​, JSON Schema, ເຈົ້າຄິດຖືກຕ້ອງແລ້ວ. ເປົ້າຫມາຍແມ່ນຄືກັນ: ບາງພາສາເພື່ອອະທິບາຍຊຸດຂໍ້ມູນການສົ່ງຕໍ່ທີ່ເປັນໄປໄດ້. ນີ້ແມ່ນບ່ອນທີ່ຄວາມຄ້າຍຄືກັນສິ້ນສຸດລົງ. ຖ້າຈາກຫນ້າ ອະນຸສັນຍາ MTProto, ຫຼືຈາກຕົ້ນໄມ້ຕົ້ນສະບັບຂອງລູກຄ້າຢ່າງເປັນທາງການ, ພວກເຮົາຈະພະຍາຍາມເປີດບາງ schema, ພວກເຮົາຈະເຫັນບາງສິ່ງບາງຢ່າງເຊັ່ນ:

int ? = Int;
long ? = Long;
double ? = Double;
string ? = String;

vector#1cb5c415 {t:Type} # [ t ] = Vector t;

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

rpc_answer_unknown#5e2ad36e = RpcDropAnswer;
rpc_answer_dropped_running#cd78e586 = RpcDropAnswer;
rpc_answer_dropped#a43ad8b7 msg_id:long seq_no:int bytes:int = RpcDropAnswer;

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

---functions---

set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:bytes = Set_client_DH_params_answer;

ping#7abe77ec ping_id:long = Pong;
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

invokeAfterMsg#cb9f372d msg_id:long query:!X = X;
invokeAfterMsgs#3dc4b4f0 msg_ids:Vector<long> query:!X = X;

account.updateProfile#78515775 flags:# first_name:flags.0?string last_name:flags.1?string about:flags.2?string = User;
account.sendChangePhoneCode#8e57deb flags:# allow_flashcall:flags.0?true phone_number:string current_number:flags.0?Bool = auth.SentCode;

ຄົນທີ່ເຫັນສິ່ງນີ້ເປັນຄັ້ງ ທຳ ອິດສາມາດຮັບຮູ້ໄດ້ພຽງແຕ່ສ່ວນ ໜຶ່ງ ຂອງສິ່ງທີ່ຂຽນ - ດີ, ນີ້ແມ່ນໂຄງສ້າງ (ເຖິງແມ່ນວ່າຊື່ຢູ່ໃສ, ຢູ່ເບື້ອງຊ້າຍຫຼືເບື້ອງຂວາ?), ມີທົ່ງນາຢູ່ໃນພວກມັນ, ປະເພດໃດນຶ່ງຕາມຫຼັງ ຈໍ້າສອງເມັດ... ອາດຈະເປັນ. ໃນທີ່ນີ້ໃນວົງເລັບມຸມມີອາດຈະເປັນແມ່ແບບເຊັ່ນໃນ C ++ (ໃນຄວາມເປັນຈິງ, ບໍ່ແມ່ນ). ແລະສັນຍາລັກອື່ນໆທັງຫມົດຫມາຍຄວາມວ່າແນວໃດ, ເຄື່ອງຫມາຍຄໍາຖາມ, ເຄື່ອງຫມາຍ exclamation, ເປີເຊັນ, hash marks (ແລະແນ່ນອນວ່າພວກເຂົາຫມາຍເຖິງສິ່ງທີ່ແຕກຕ່າງກັນໃນສະຖານທີ່ຕ່າງໆ), ບາງຄັ້ງປະຈຸບັນແລະບາງຄັ້ງບໍ່ແມ່ນ, ເລກຖານສິບຫົກ - ແລະສໍາຄັນທີ່ສຸດ, ວິທີການໄດ້ຮັບຈາກນີ້. ປົກກະຕິ (ເຊິ່ງຈະບໍ່ຖືກປະຕິເສດໂດຍເຄື່ອງແມ່ຂ່າຍ) byte stream? ທ່ານຈະຕ້ອງອ່ານເອກະສານ (ແມ່ນແລ້ວ, ມີການເຊື່ອມຕໍ່ກັບ schema ໃນລຸ້ນ JSON ຢູ່ໃກ້ໆ - ແຕ່ນັ້ນບໍ່ໄດ້ເຮັດໃຫ້ມັນຊັດເຈນກວ່ານີ້).

ເປີດຫນ້າ ການຈັດລໍາດັບຂໍ້ມູນຖານສອງ ແລະ dive ເຂົ້າໄປໃນໂລກ magical ຂອງເຫັດແລະ discrete ຄະນິດສາດ, ບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນກັບ matan ໃນປີທີ 4. ຕົວອັກສອນ, ປະເພດ, ຄຸນຄ່າ, ຕົວປະສົມ, ຕົວປະສົມທີ່ມີປະໂຫຍດ, ຮູບແບບປົກກະຕິ, ປະເພດປະສົມ, ປະເພດໂພລີໂມຟິກ... ແລະນັ້ນແມ່ນໜ້າທຳອິດເທົ່ານັ້ນ! ຕໍ່ໄປລໍຖ້າທ່ານ ພາສາ TL, ເຊິ່ງເຖິງແມ່ນວ່າມັນມີຕົວຢ່າງຂອງຄໍາຮ້ອງຂໍແລະການຕອບໂຕ້ເລັກນ້ອຍ, ບໍ່ໄດ້ໃຫ້ຄໍາຕອບໃດໆຕໍ່ກັບກໍລະນີທົ່ວໄປຫຼາຍ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານຈະຕ້ອງຜ່ານ retelling ຂອງຄະນິດສາດທີ່ແປຈາກພາສາລັດເຊຍເປັນພາສາອັງກິດໃນອີກແປດຝັງ. ໜ້າ!

ຜູ້ອ່ານທີ່ຄຸ້ນເຄີຍກັບພາສາທີ່ມີປະໂຫຍດແລະປະເພດອັດຕະໂນມັດ inference ຈະ, ແນ່ນອນ, ເບິ່ງພາສາຄໍາອະທິບາຍໃນພາສານີ້, ເຖິງແມ່ນວ່າຈາກຕົວຢ່າງ, ຫຼາຍທີ່ຄຸ້ນເຄີຍ, ແລະສາມາດເວົ້າໄດ້ວ່ານີ້ແມ່ນຕົວຈິງແລ້ວບໍ່ບໍ່ດີໃນຫຼັກການ. ຂໍ້​ຄັດຄ້ານ​ຄື:

• ແມ່ນແລ້ວ, ເປົ້າ​ຫມາຍ ສຽງດີ, ແຕ່ອະນິຈາ, ນາງ ບໍ່ບັນລຸໄດ້
• ການສຶກສາຢູ່ໃນມະຫາວິທະຍາໄລລັດເຊຍແຕກຕ່າງກັນເຖິງແມ່ນວ່າໃນບັນດາວິຊາສະເພາະດ້ານໄອທີ - ບໍ່ແມ່ນທຸກຄົນໄດ້ຮຽນວິຊາທີ່ສອດຄ້ອງກັນ
• ສຸດທ້າຍ, ດັ່ງທີ່ພວກເຮົາຈະເຫັນ, ໃນການປະຕິບັດມັນແມ່ນ ບໍ່ຕ້ອງການ, ເນື່ອງຈາກວ່າມີພຽງແຕ່ຊຸດຍ່ອຍທີ່ຈໍາກັດຂອງແມ້ກະທັ້ງ TL ທີ່ໄດ້ອະທິບາຍແມ່ນຖືກນໍາໃຊ້

ດັ່ງທີ່ກ່າວ LeoNerd ໃນຊ່ອງທາງ #perl ໃນເຄືອຂ່າຍ FreeNode IRC, ຜູ້ທີ່ພະຍາຍາມປະຕິບັດປະຕູຈາກ Telegram ຫາ Matrix (ການແປຄໍາອ້າງອີງແມ່ນບໍ່ຖືກຕ້ອງຈາກຫນ່ວຍຄວາມຈໍາ):

ມັນຮູ້ສຶກຄືກັບວ່າບາງຄົນໄດ້ຖືກນໍາສະເຫນີໃຫ້ພິມທິດສະດີເປັນຄັ້ງທໍາອິດ, ຕື່ນເຕັ້ນ, ແລະເລີ່ມພະຍາຍາມຫຼີ້ນກັບມັນ, ບໍ່ສົນໃຈແທ້ໆວ່າມັນຈໍາເປັນໃນການປະຕິບັດ.

ເບິ່ງຕົວທ່ານເອງ, ຖ້າຄວາມຕ້ອງການສໍາລັບປະເພດເປົ່າ (int, ຍາວ, ແລະອື່ນໆ) ເປັນສິ່ງທີ່ປະຖົມບໍ່ໄດ້ຕັ້ງຄໍາຖາມ - ໃນທີ່ສຸດພວກເຂົາຕ້ອງໄດ້ຮັບການປະຕິບັດດ້ວຍຕົນເອງ - ຕົວຢ່າງ, ໃຫ້ພະຍາຍາມເອົາມາຈາກພວກມັນ. vector. ນັ້ນແມ່ນ, ໃນຄວາມເປັນຈິງ, ຂບວນ, ຖ້າ ຫາກ ທ່ານ ໂທ ຫາ ສິ່ງ ທີ່ ໄດ້ ຮັບ ໂດຍ ຊື່ ທີ່ ເຫມາະ ສົມ ຂອງ ເຂົາ ເຈົ້າ .

ແຕ່ກ່ອນ

ລາຍລະອຽດສັ້ນໆຂອງຊຸດຍ່ອຍຂອງ syntax TL ສໍາລັບຜູ້ທີ່ບໍ່ໄດ້ອ່ານເອກະສານທາງການ

constructor = Type;
myVec ids:Vector<long> = Type;

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

constructorOne#crc32 field1:int = PolymorType;
constructorTwo#2crc32 field_a:long field_b:Type3 field_c:int = PolymorType;
constructorThree#deadcrc bit_flags_of_what_really_present:# optional_field4:bit_flags_of_what_really_present.1?Type = PolymorType;

an_id#12abcd34 id:int = Type3;
a_null#6789cdef = Type3;

ຄໍານິຍາມເລີ່ມຕົ້ນສະເຫມີ ຜູ້ກໍ່ສ້າງ, ຫຼັງຈາກນັ້ນທາງເລືອກ (ໃນການປະຕິບັດ - ສະເຫມີ) ໂດຍຜ່ານສັນຍາລັກ # ຕ້ອງ CRC32 ຈາກສະຕຣິງຄໍາອະທິບາຍປົກກະຕິຂອງປະເພດນີ້. ຕໍ່ໄປແມ່ນລາຍລະອຽດຂອງຊ່ອງຂໍ້ມູນ; ຖ້າພວກມັນມີຢູ່, ປະເພດອາດຈະຫວ່າງເປົ່າ. ນີ້ທັງຫມົດສິ້ນສຸດລົງດ້ວຍເຄື່ອງຫມາຍເທົ່າທຽມກັນ, ຊື່ຂອງປະເພດທີ່ຜູ້ກໍ່ສ້າງນີ້ - ໃນຄວາມເປັນຈິງ, ປະເພດຍ່ອຍ - ເປັນ. ຜູ້ຊາຍທີ່ຢູ່ເບື້ອງຂວາຂອງເຄື່ອງຫມາຍເທົ່າກັບ polymorphic - ນັ້ນແມ່ນ, ປະເພດສະເພາະຈໍານວນຫນຶ່ງສາມາດກົງກັບມັນ.

ຖ້າຄໍານິຍາມເກີດຂື້ນຫຼັງຈາກເສັ້ນ ---functions---, ຫຼັງຈາກນັ້ນ syntax ຈະຍັງຄົງຄືເກົ່າ, ແຕ່ຄວາມຫມາຍຈະແຕກຕ່າງກັນ: ຜູ້ກໍ່ສ້າງຈະກາຍເປັນຊື່ຂອງຫນ້າທີ່ RPC, ທົ່ງນາຈະກາຍເປັນຕົວກໍານົດການ (ດີ, ນັ້ນແມ່ນ, ມັນຈະຍັງຄົງເປັນໂຄງສ້າງດຽວກັນ, ດັ່ງທີ່ໄດ້ອະທິບາຍຂ້າງລຸ່ມນີ້. , ນີ້ພຽງແຕ່ຈະເປັນຄວາມຫມາຍທີ່ໄດ້ຮັບມອບຫມາຍ), ແລະ "ປະເພດ polymorphic" - ປະເພດຂອງຜົນໄດ້ຮັບກັບຄືນມາ. ຄວາມຈິງ, ມັນຈະຍັງຄົງເປັນ polymorphic - ພຽງແຕ່ກໍານົດຢູ່ໃນພາກ ---types---, ແຕ່ຜູ້ກໍ່ສ້າງນີ້ຈະ "ບໍ່ຖືກພິຈາລະນາ". overloading ປະເພດຂອງຫນ້າທີ່ເອີ້ນວ່າໂດຍການໂຕ້ຖຽງຂອງພວກເຂົາ, i.e. ສໍາລັບເຫດຜົນບາງຢ່າງ, ຫຼາຍຫນ້າທີ່ທີ່ມີຊື່ດຽວກັນແຕ່ລາຍເຊັນທີ່ແຕກຕ່າງກັນ, ເຊັ່ນດຽວກັບ C ++, ບໍ່ໄດ້ຖືກສະຫນອງໃຫ້ຢູ່ໃນ TL.

ເປັນຫຍັງ "constructor" ແລະ "polymorphic" ຖ້າມັນບໍ່ແມ່ນ OOP? ແລ້ວ, ໃນຄວາມເປັນຈິງ, ມັນຈະງ່າຍຂຶ້ນສໍາລັບຜູ້ໃດຜູ້ຫນຶ່ງທີ່ຈະຄິດກ່ຽວກັບເລື່ອງນີ້ໃນເງື່ອນໄຂ OOP - ປະເພດ polymorphic ເປັນຫ້ອງຮຽນທີ່ບໍ່ມີຕົວຕົນ, ແລະຜູ້ກໍ່ສ້າງແມ່ນຊັ້ນຮຽນໂດຍກົງຂອງມັນ, ແລະ. final ໃນຄໍາສັບຕ່າງໆຂອງພາສາຈໍານວນຫນຶ່ງ. ໃນຄວາມເປັນຈິງ, ແນ່ນອນ, ທີ່ນີ້ເທົ່ານັ້ນ ຄວາມຄ້າຍຄືກັນ ດ້ວຍວິທີການກໍ່ສ້າງເກີນຈິງໃນພາສາການຂຽນໂປລແກລມ OO. ເນື່ອງຈາກວ່ານີ້ແມ່ນພຽງແຕ່ໂຄງສ້າງຂໍ້ມູນ, ບໍ່ມີວິທີການ (ເຖິງແມ່ນວ່າຄໍາອະທິບາຍຂອງຫນ້າທີ່ແລະວິທີການເພີ່ມເຕີມແມ່ນຂ້ອນຂ້າງສາມາດສ້າງຄວາມສັບສົນໃນຫົວທີ່ພວກເຂົາມີຢູ່, ແຕ່ນັ້ນແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນ) - ທ່ານສາມາດຄິດເຖິງ constructor ເປັນມູນຄ່າຈາກ. ເຊິ່ງ ກໍາລັງກໍ່ສ້າງ ພິມໃນເວລາທີ່ອ່ານ byte stream.

ນີ້ເກີດຂຶ້ນແນວໃດ? deserializer, ເຊິ່ງສະເຫມີອ່ານ 4 bytes, ເຫັນຄ່າ 0xcrc32 - ແລະເຂົ້າໃຈສິ່ງທີ່ຈະເກີດຂຶ້ນຕໍ່ໄປ field1 ກັບ​ປະ​ເພດ​ int, i.e. ອ່ານ 4 bytes ຢ່າງແທ້ຈິງ, ໃນນີ້ພາກສະຫນາມ overlying ກັບປະເພດ PolymorType ອ່ານ. ເຫັນ 0x2crc32 ແລະເຂົ້າໃຈວ່າມີສອງຂົງເຂດຕື່ມອີກ, ທໍາອິດ long, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາອ່ານ 8 bytes. ແລະຫຼັງຈາກນັ້ນອີກເທື່ອຫນຶ່ງປະເພດສະລັບສັບຊ້ອນ, ເຊິ່ງຖືກ deserialized ໃນທາງດຽວກັນ. ຍົກ​ຕົວ​ຢ່າງ, Type3 ສາມາດໄດ້ຮັບການປະກາດໃນວົງຈອນທັນທີທີ່ສອງ constructors, ຕາມລໍາດັບ, ຫຼັງຈາກນັ້ນເຂົາເຈົ້າຈະຕ້ອງໄດ້ພົບ 0x12abcd34, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງໄດ້ອ່ານ 4 bytes ເພີ່ມເຕີມ int, ຫຼື 0x6789cdef, ຫຼັງຈາກນັ້ນຈະບໍ່ມີຫຍັງ. ສິ່ງອື່ນ - ທ່ານຈໍາເປັນຕ້ອງຖິ້ມຂໍ້ຍົກເວັ້ນ. ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກນັ້ນພວກເຮົາກັບຄືນໄປບ່ອນອ່ານ 4 bytes int ທົ່ງນາ field_c в constructorTwo ແລະດ້ວຍວ່າພວກເຮົາສໍາເລັດການອ່ານຂອງພວກເຮົາ PolymorType.

ສຸດທ້າຍ, ຖ້າທ່ານຖືກຈັບ 0xdeadcrc ການ constructorThree, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງຈະກາຍເປັນຄວາມສັບສົນຫຼາຍ. ພາກສະຫນາມທໍາອິດຂອງພວກເຮົາແມ່ນ bit_flags_of_what_really_present ກັບ​ປະ​ເພດ​ # - ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນພຽງແຕ່ນາມແຝງສໍາລັບປະເພດ nat, ຊຶ່ງຫມາຍຄວາມວ່າ "ຕົວເລກທໍາມະຊາດ". ນັ້ນແມ່ນ, ໃນຄວາມເປັນຈິງ, unsigned int ແມ່ນ, ໂດຍວິທີທາງການ, ເປັນກໍລະນີດຽວໃນເວລາທີ່ຕົວເລກທີ່ບໍ່ໄດ້ເຊັນຢູ່ໃນວົງຈອນທີ່ແທ້ຈິງ. ດັ່ງນັ້ນ, ຕໍ່ໄປແມ່ນການກໍ່ສ້າງທີ່ມີເຄື່ອງຫມາຍຄໍາຖາມ, ຫມາຍຄວາມວ່າພາກສະຫນາມນີ້ - ມັນຈະມີຢູ່ໃນສາຍພຽງແຕ່ຖ້າຫາກວ່າບິດທີ່ສອດຄ້ອງກັນໄດ້ຖືກກໍານົດຢູ່ໃນພາກສະຫນາມທີ່ອ້າງເຖິງ (ປະມານຄືກັບຕົວປະຕິບັດການ ternary). ດັ່ງນັ້ນ, ໃຫ້ສົມມຸດວ່າບິດນີ້ຖືກຕັ້ງ, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ອ່ານພາກສະຫນາມເຊັ່ນ Type, ເຊິ່ງໃນຕົວຢ່າງຂອງພວກເຮົາມີ 2 constructors. ອັນໜຶ່ງແມ່ນຫວ່າງເປົ່າ (ປະກອບດ້ວຍຕົວລະບຸເທົ່ານັ້ນ), ອີກອັນໜຶ່ງມີຊ່ອງຂໍ້ມູນ ids ກັບ​ປະ​ເພດ​ ids:Vector<long>.

ທ່ານອາດຈະຄິດວ່າທັງແມ່ແບບແລະທົ່ວໄປແມ່ນຢູ່ໃນ pros ຫຼື Java. ແຕ່ບໍ່ມີ. ເກືອບ​ທັງ​ຫມົດ. ນີ້ ດຽວ ກໍ​ລະ​ນີ​ຂອງ​ການ​ນໍາ​ໃຊ້​ວົງ​ເລັບ​ມຸມ​ໃນ​ວົງ​ຈອນ​ທີ່​ແທ້​ຈິງ​, ແລະ​ມັນ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ພຽງ​ແຕ່​ສໍາ​ລັບ Vector​. ໃນກະແສ byte, ເຫຼົ່ານີ້ຈະເປັນ 4 CRC32 bytes ສໍາລັບປະເພດ Vector ຕົວຂອງມັນເອງ, ສະເຫມີດຽວກັນ, ຫຼັງຈາກນັ້ນ 4 bytes - ຈໍານວນຂອງອົງປະກອບ array, ແລະຫຼັງຈາກນັ້ນອົງປະກອບເຫຼົ່ານີ້ເອງ.

ຕື່ມນີ້ຄວາມຈິງທີ່ວ່າ serialization ເກີດຂຶ້ນສະເຫມີໃນຄໍາສັບຕ່າງໆຂອງ 4 bytes, ທຸກປະເພດແມ່ນການຄູນຂອງມັນ - ປະເພດທີ່ສ້າງຂຶ້ນແມ່ນຍັງອະທິບາຍ. bytes и string ມີ serialization ຄູ່ມືຂອງຄວາມຍາວແລະການຈັດຕໍາແຫນ່ງນີ້ໂດຍ 4 - ດີ, ມັນເບິ່ງຄືວ່າປົກກະຕິແລະເຖິງແມ່ນວ່າຂ້ອນຂ້າງປະສິດທິພາບ? ເຖິງແມ່ນວ່າ TL ໄດ້ຖືກອ້າງວ່າເປັນ serialization binary ທີ່ມີປະສິດຕິຜົນ, ກັບ hell ກັບພວກເຂົາ, ດ້ວຍການຂະຫຍາຍພຽງແຕ່ກ່ຽວກັບສິ່ງໃດ, ເຖິງແມ່ນວ່າຄ່າ Boolean ແລະສາຍຕົວອັກສອນດຽວເຖິງ 4 bytes, JSON ຍັງຈະຫນາແຫນ້ນຫຼາຍບໍ? ເບິ່ງ, ເຖິງແມ່ນວ່າຊ່ອງທີ່ບໍ່ຈໍາເປັນສາມາດຂ້າມໄດ້ໂດຍທຸງນ້ອຍ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຂ້ອນຂ້າງດີ, ແລະເຖິງແມ່ນວ່າສາມາດຂະຫຍາຍໄດ້ໃນອະນາຄົດ, ດັ່ງນັ້ນເປັນຫຍັງຈຶ່ງບໍ່ເພີ່ມຊ່ອງຂໍ້ມູນທາງເລືອກໃຫມ່ໃຫ້ກັບຜູ້ກໍ່ສ້າງໃນພາຍຫລັງ?..

ແຕ່ບໍ່, ຖ້າທ່ານອ່ານບໍ່ແມ່ນຄໍາອະທິບາຍສັ້ນໆຂອງຂ້ອຍ, ແຕ່ເອກະສານເຕັມ, ແລະຄິດກ່ຽວກັບການປະຕິບັດ. ກ່ອນອື່ນ ໝົດ, CRC32 ຂອງຜູ້ກໍ່ສ້າງຖືກຄິດໄລ່ຕາມເສັ້ນປົກກະຕິຂອງຄໍາອະທິບາຍຂໍ້ຄວາມຂອງໂຄງການ (ເອົາພື້ນທີ່ຫວ່າງເພີ່ມເຕີມ, ແລະອື່ນໆ) - ດັ່ງນັ້ນຖ້າມີຊ່ອງຂໍ້ມູນໃຫມ່, ເສັ້ນຄໍາອະທິບາຍປະເພດຈະປ່ຽນແປງ, ແລະດ້ວຍເຫດນີ້ CRC32 ຂອງມັນແລະ. , ດັ່ງນັ້ນ, serialization. ແລະລູກຄ້າເກົ່າຈະເຮັດແນວໃດຖ້າລາວໄດ້ຮັບພາກສະຫນາມທີ່ມີທຸງໃຫມ່, ແລະລາວບໍ່ຮູ້ວ່າຈະເຮັດແນວໃດກັບພວກເຂົາຕໍ່ໄປ?

ອັນທີສອງ, ໃຫ້ເຮົາຈື່ CRC32, ເຊິ່ງໄດ້ຖືກນໍາໃຊ້ໃນທີ່ນີ້ເປັນສິ່ງຈໍາເປັນ ຟັງຊັນ hash ເພື່ອກໍານົດຢ່າງເປັນເອກະລັກວ່າປະເພດໃດຈະຖືກ (de)serialized. ໃນທີ່ນີ້ພວກເຮົາກໍາລັງປະເຊີນກັບບັນຫາການປະທະກັນ - ແລະບໍ່, ຄວາມເປັນໄປໄດ້ບໍ່ແມ່ນຫນຶ່ງໃນ 232, ແຕ່ຫຼາຍກວ່າເກົ່າ. ໃຜຈື່ໄດ້ວ່າ CRC32 ຖືກອອກແບບມາເພື່ອກວດພົບ (ແລະແກ້ໄຂ) ຂໍ້ຜິດພາດໃນຊ່ອງທາງການສື່ສານ, ແລະປັບປຸງຄຸນສົມບັດເຫຼົ່ານີ້ເພື່ອຄວາມເສຍຫາຍຂອງຄົນອື່ນ? ຕົວຢ່າງ, ມັນບໍ່ສົນໃຈກັບການຈັດລຽງ bytes ຄືນໃໝ່: ຖ້າທ່ານຄິດໄລ່ CRC32 ຈາກສອງແຖວ, ໃນທີສອງທ່ານແລກປ່ຽນ 4 bytes ທໍາອິດກັບ 4 bytes ຕໍ່ໄປ - ມັນຈະຄືກັນ. ເມື່ອການປ້ອນຂໍ້ມູນຂອງພວກເຮົາແມ່ນຂໍ້ຄວາມຈາກຕົວອັກສອນລາຕິນ (ແລະເຄື່ອງໝາຍວັກຕອນເລັກນ້ອຍ), ແລະຊື່ເຫຼົ່ານີ້ບໍ່ແມ່ນແບບສຸ່ມໂດຍສະເພາະ, ຄວາມເປັນໄປໄດ້ຂອງການຈັດລຽງດັ່ງກ່າວເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ໂດຍວິທີທາງການ, ຜູ້ທີ່ກວດເບິ່ງວ່າມີຫຍັງແດ່? ແທ້ CRC32? ໜຶ່ງໃນລະຫັດແຫຼ່ງຕົ້ນໆ (ແມ້ແຕ່ກ່ອນ Waltman) ມີຟັງຊັນ hash ທີ່ຄູນແຕ່ລະຕົວອັກສອນດ້ວຍຕົວເລກ 239, ສະນັ້ນຄົນເຫຼົ່ານີ້ຮັກແພງຫຼາຍ, ha ha!

ສຸດທ້າຍ, ໂອເຄ, ພວກເຮົາຮູ້ວ່າຜູ້ກໍ່ສ້າງທີ່ມີປະເພດພາກສະຫນາມ Vector<int> и Vector<PolymorType> ຈະມີ CRC32 ທີ່ແຕກຕ່າງກັນ. ຈະເປັນແນວໃດກ່ຽວກັບການປະຕິບັດອອນໄລນ໌? ແລະຈາກທັດສະນະທາງທິດສະດີ, ນີ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງປະເພດ? ໃຫ້ເວົ້າວ່າພວກເຮົາຜ່ານ array ຂອງສິບພັນຕົວເລກ, ດີກັບ Vector<int> ທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງ, ຄວາມຍາວແລະອີກ 40000 bytes. ຈະເປັນແນວໃດຖ້າວ່ານີ້ Vector<Type2>, ເຊິ່ງປະກອບດ້ວຍພຽງແຕ່ຫນຶ່ງພາກສະຫນາມ int ແລະມັນຢູ່ໃນປະເພດດຽວ - ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດຊ້ໍາ 10000xabcdef0 34 ເທື່ອແລະຫຼັງຈາກນັ້ນ 4 bytes? int, ຫຼືພາສາແມ່ນສາມາດ INDEPEND ມັນສໍາລັບພວກເຮົາຈາກຜູ້ກໍ່ສ້າງ fixedVec ແລະແທນທີ່ຈະ 80000 bytes, ໂອນອີກເທື່ອຫນຶ່ງພຽງແຕ່ 40000?

ນີ້ບໍ່ແມ່ນຄໍາຖາມທາງທິດສະດີທີ່ບໍ່ມີປະໂຫຍດເລີຍ - ຈິນຕະນາການວ່າທ່ານໄດ້ຮັບບັນຊີລາຍຊື່ຂອງຜູ້ໃຊ້ກຸ່ມ, ແຕ່ລະຄົນມີ id, ຊື່, ນາມສະກຸນ - ຄວາມແຕກຕ່າງຂອງຈໍານວນຂໍ້ມູນທີ່ໂອນຜ່ານການເຊື່ອມຕໍ່ມືຖືສາມາດມີຄວາມສໍາຄັນ. ມັນເປັນທີ່ຊັດເຈນປະສິດທິຜົນຂອງ Telegram serialization ທີ່ຖືກໂຄສະນາໃຫ້ພວກເຮົາ.

ດັ່ງນັ້ນ…

vector, ເຊິ່ງບໍ່ເຄີຍປ່ອຍອອກມາ

ຖ້າທ່ານພະຍາຍາມແລ່ນຜ່ານຫນ້າຄໍາອະທິບາຍຂອງເຄື່ອງປະສົມແລະອື່ນໆ, ທ່ານຈະເຫັນວ່າ vector (ແລະແມ້ກະທັ້ງ matrix) ກໍາລັງພະຍາຍາມຢ່າງເປັນທາງການເພື່ອໃຫ້ຜົນຜະລິດຜ່ານ tuples ຂອງຫຼາຍໆແຜ່ນ. ແຕ່ໃນທີ່ສຸດພວກເຂົາລືມ, ຂັ້ນຕອນສຸດທ້າຍແມ່ນຂ້າມໄປ, ແລະຄໍານິຍາມຂອງ vector ແມ່ນໃຫ້ງ່າຍດາຍ, ເຊິ່ງຍັງບໍ່ທັນໄດ້ຜູກມັດກັບປະເພດໃດຫນຶ່ງ. ແມ່ນຫຍັງ? ໃນພາສາ ການຂຽນໂປແກຼມ, ໂດຍສະເພາະທີ່ເປັນປະໂຫຍດ, ມັນເປັນເລື່ອງປົກກະຕິທີ່ຈະອະທິບາຍໂຄງສ້າງແບບ recursively - compiler ທີ່ມີການປະເມີນຜົນຂີ້ກຽດຂອງມັນຈະເຂົ້າໃຈແລະເຮັດທຸກຢ່າງຂອງມັນເອງ. ໃນພາສາ serialization ຂໍ້ມູນ ສິ່ງທີ່ຕ້ອງການແມ່ນປະສິດທິພາບ: ມັນພຽງພໍທີ່ຈະອະທິບາຍພຽງແຕ່ ບັນຊີລາຍຊື່, i.e. ໂຄງສ້າງຂອງສອງອົງປະກອບ - ທໍາອິດແມ່ນອົງປະກອບຂໍ້ມູນ, ອັນທີສອງແມ່ນໂຄງສ້າງດຽວກັນຂອງມັນເອງຫຼືພື້ນທີ່ຫວ່າງສໍາລັບຫາງ (pack. (cons) ໃນ Lisp). ແຕ່ນີ້ແນ່ນອນຈະຮຽກຮ້ອງໃຫ້ມີ ແຕ່ລະຄົນ ອົງປະກອບໃຊ້ 4 bytes ເພີ່ມເຕີມ (CRC32 ໃນກໍລະນີໃນ TL) ເພື່ອອະທິບາຍປະເພດຂອງມັນ. array ຍັງສາມາດອະທິບາຍໄດ້ຢ່າງງ່າຍດາຍ ຂະຫນາດຄົງທີ່, ແຕ່ໃນກໍລະນີຂອງ array ຂອງຄວາມຍາວທີ່ບໍ່ຮູ້ຈັກລ່ວງຫນ້າ, ພວກເຮົາແຍກອອກ.

ດັ່ງນັ້ນ, ເນື່ອງຈາກ TL ບໍ່ອະນຸຍາດໃຫ້ອອກ vector, ມັນຕ້ອງໄດ້ຮັບການເພີ່ມຢູ່ດ້ານຂ້າງ. ໃນທີ່ສຸດເອກະສານກ່າວວ່າ:

Serialization ໃຊ້ constructor ດຽວກັນ "vector" (const 0x1cb5c415 = crc32("vector t:Type # [ t ] = Vector t") ທີ່ບໍ່ຂຶ້ນກັບຄ່າສະເພາະຂອງຕົວແປຂອງປະເພດ t.

ມູນຄ່າຂອງພາລາມິເຕີທາງເລືອກ t ບໍ່ໄດ້ມີສ່ວນຮ່ວມໃນ serialization ນັບຕັ້ງແຕ່ມັນແມ່ນມາຈາກປະເພດຜົນໄດ້ຮັບ (ຮູ້ຈັກສະເຫມີກ່ອນທີ່ຈະ deserialization).

ເບິ່ງຢ່າງໃກ້ຊິດ: vector {t:Type} # [ t ] = Vector t - ແຕ່ ບໍ່ມີບ່ອນໃດ ຄໍານິຍາມນີ້ເອງບໍ່ໄດ້ບອກວ່າຕົວເລກທໍາອິດຕ້ອງເທົ່າກັບຄວາມຍາວຂອງ vector! ແລະມັນບໍ່ໄດ້ມາຈາກທຸກບ່ອນ. ນີ້ແມ່ນການມອບໃຫ້ທີ່ຕ້ອງໄດ້ຮັບການຮັກສາຢູ່ໃນໃຈແລະປະຕິບັດດ້ວຍມືຂອງທ່ານ. ຢູ່ບ່ອນອື່ນ, ເອກະສານຍັງບອກຢ່າງຊື່ສັດວ່າປະເພດບໍ່ແມ່ນຕົວຈິງ:

Vector t polymorphic pseudotype ແມ່ນ "ປະເພດ" ທີ່ມີມູນຄ່າເປັນລໍາດັບຂອງຄ່າຂອງປະເພດ t, ບໍ່ວ່າຈະເປັນກ່ອງຫຼືເປົ່າ.

... ແຕ່ບໍ່ໄດ້ສຸມໃສ່ມັນ. ໃນເວລາທີ່ທ່ານ, ເມື່ອຍຂອງການ wading ໂດຍຜ່ານການ stretching ຂອງຄະນິດສາດ (ບາງທີອາດຮູ້ຈັກກັບທ່ານຈາກຫຼັກສູດວິທະຍາໄລ), ຕັດສິນໃຈທີ່ຈະຍອມແພ້ແລະຕົວຈິງແລ້ວເບິ່ງວິທີການເຮັດວຽກກັບມັນໃນການປະຕິບັດ, ຄວາມປະທັບໃຈທີ່ຍັງເຫຼືອຢູ່ໃນຫົວຂອງທ່ານແມ່ນວ່ານີ້ແມ່ນຮ້າຍແຮງ. ຄະນິດສາດຢູ່ໃນຫຼັກ, ມັນໄດ້ຖືກ invented ຢ່າງຊັດເຈນໂດຍ Cool People (ນັກຄະນິດສາດສອງຄົນ - ຜູ້ຊະນະ ACM), ແລະບໍ່ພຽງແຕ່ໃຜ. ເປົ້າຫມາຍ - ເພື່ອສະແດງໃຫ້ເຫັນ off - ໄດ້ບັນລຸຜົນ.

ໂດຍວິທີທາງການ, ກ່ຽວກັບຈໍານວນ. ໃຫ້ພວກເຮົາເຕືອນທ່ານວ່າ # ມັນເປັນຄໍາສັບຄ້າຍຄື nat, ຈໍາ​ນວນ​ທໍາ​ມະ​ຊາດ​:

ມີການສະແດງອອກປະເພດ (type-expr) ແລະການສະແດງຕົວເລກ (nat-expr). ຢ່າງໃດກໍຕາມ, ພວກເຂົາເຈົ້າໄດ້ຖືກກໍານົດວິທີການດຽວກັນ.

type-expr ::= expr
nat-expr ::= expr

ແຕ່ໃນໄວຍາກອນເຂົາເຈົ້າໄດ້ຖືກອະທິບາຍໃນລັກສະນະດຽວກັນ, i.e. ຄວາມແຕກຕ່າງນີ້ຕ້ອງໄດ້ຮັບການຈົດຈໍາອີກເທື່ອຫນຶ່ງແລະປະຕິບັດດ້ວຍມື.

ແລ້ວ, ແມ່ນແລ້ວ, ປະເພດແມ່ແບບ (vector<int>, vector<User>) ມີຕົວລະບຸທົ່ວໄປ (#1cb5c415), i.e. ຖ້າທ່ານຮູ້ວ່າການໂທຖືກປະກາດເປັນ

users.getUsers#d91a548 id:Vector<InputUser> = Vector<User>;

ຫຼັງຈາກນັ້ນ, ທ່ານບໍ່ໄດ້ລໍຖ້າພຽງແຕ່ vector, ແຕ່ vector ຂອງຜູ້ໃຊ້. ຊັດເຈນກວ່ານັ້ນ, ຄວນ ລໍຖ້າ - ໃນລະຫັດທີ່ແທ້ຈິງ, ທຸກໆອົງປະກອບ, ຖ້າບໍ່ແມ່ນປະເພດເປົ່າ, ຈະມີຕົວສ້າງ, ແລະໃນທາງທີ່ດີໃນການປະຕິບັດມັນຈໍາເປັນຕ້ອງກວດເບິ່ງ - ແຕ່ພວກເຮົາຖືກສົ່ງກັບທຸກໆອົງປະກອບຂອງ vector ນີ້. ປະເພດນັ້ນ? ຈະເປັນແນວໃດຖ້າວ່າມັນເປັນບາງປະເພດຂອງ PHP, ໃນ array ສາມາດປະກອບມີປະເພດຕ່າງໆໃນອົງປະກອບທີ່ແຕກຕ່າງກັນ?

ໃນຈຸດນີ້, ທ່ານເລີ່ມຄິດວ່າ - ດັ່ງກ່າວເປັນ TL ມີຄວາມຈໍາເປັນບໍ? ບາງທີສໍາລັບໂຄງຮ່າງການມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ serializer ຂອງມະນຸດ, protobuf ດຽວກັນທີ່ມີແລ້ວ? ນັ້ນແມ່ນທິດສະດີ, ໃຫ້ເບິ່ງການປະຕິບັດ.

ການປະຕິບັດ TL ທີ່ມີຢູ່ແລ້ວໃນລະຫັດ

TL ເກີດຢູ່ໃນຄວາມເລິກຂອງ VKontakte ເຖິງແມ່ນວ່າກ່ອນທີ່ຈະມີເຫດການທີ່ມີຊື່ສຽງທີ່ມີການຂາຍຮຸ້ນຂອງ Durov ແລະ (ແນ່ນອນ), ເຖິງແມ່ນວ່າກ່ອນທີ່ຈະພັດທະນາຂອງ Telegram ໄດ້ເລີ່ມຕົ້ນ. ແລະໃນແຫຼ່ງເປີດ ລະຫັດແຫຼ່ງຂອງການປະຕິບັດຄັ້ງທໍາອິດ ທ່ານສາມາດຊອກຫາ crutches ຕະຫລົກຫຼາຍ. ແລະພາສາຕົວມັນເອງໄດ້ຖືກປະຕິບັດຢູ່ທີ່ນັ້ນຢ່າງເຕັມທີ່ຫຼາຍກ່ວາມັນຢູ່ໃນ Telegram. ຕົວຢ່າງ, hashes ບໍ່ໄດ້ຖືກນໍາໃຊ້ທັງຫມົດໃນໂຄງການ (ຫມາຍຄວາມວ່າເປັນ pseudotype ສ້າງຂຶ້ນໃນ (ຄ້າຍຄື vector) ທີ່ມີພຶດຕິກໍາ deviant). ຫຼື

Templates are not used now. Instead, the same universal constructors (for example, vector {t:Type} [t] = Vector t) are used w

ແຕ່ໃຫ້ພວກເຮົາພິຈາລະນາ, ສໍາລັບຄວາມສົມບູນ, ເພື່ອຕິດຕາມ, ດັ່ງນັ້ນການເວົ້າ, evolution ຂອງ Giant ຂອງຄວາມຄິດ.

#define ZHUKOV_BYTES_HACK

#ifdef ZHUKOV_BYTES_HACK

/* dirty hack for Zhukov request */

ຫຼືງາມອັນນີ້:

    static const char *reserved_words_polymorhic[] = {

      "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", NULL

      };

ຊິ້ນນີ້ແມ່ນກ່ຽວກັບແມ່ແບບເຊັ່ນ:

intHash {alpha:Type} vector<coupleInt<alpha>> = IntHash<alpha>;

ນີ້ແມ່ນຄໍານິຍາມຂອງປະເພດແມ່ແບບ hashmap ເປັນ vector ຂອງ int - ປະເພດຄູ່. ໃນ C++ ມັນ​ຈະ​ເບິ່ງ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ເຊັ່ນ​ນີ້​:

    template <T> class IntHash {
      vector<pair<int,T>> _map;
    }

ດັ່ງນັ້ນ, alpha - ຄໍາສໍາຄັນ! ແຕ່ພຽງແຕ່ຢູ່ໃນ C ++ ທີ່ທ່ານສາມາດຂຽນ T, ແຕ່ທ່ານຄວນຂຽນ alpha, beta ... ແຕ່ບໍ່ມີຫຼາຍກ່ວາ 8 ຕົວກໍານົດການ, ນັ້ນແມ່ນບ່ອນທີ່ fantasy ສິ້ນສຸດລົງ. ເບິ່ງ​ຄື​ວ່າ​ຄັ້ງ​ໜຶ່ງ​ຢູ່​ທີ່​ເມືອງ St.

-- Надо сделать в TL шаблоны
-- Бл... Ну пусть параметры зовут альфа, бета,... Какие там ещё буквы есть... О, тэта!
-- Грамматика? Ну потом напишем

-- Смотрите, какой я синтаксис придумал для шаблонов и вектора!
-- Ты долбанулся, как мы это парсить будем?
-- Да не ссыте, он там один в схеме, захаркодить -- и ок

ແຕ່ນີ້ແມ່ນກ່ຽວກັບການພິມເຜີຍແຜ່ຄັ້ງທໍາອິດຂອງ TL "ໂດຍທົ່ວໄປ". ຂໍໃຫ້ກ້າວໄປສູ່ການພິຈາລະນາການປະຕິບັດໃນລູກຄ້າ Telegram ເອງ.

ຄໍາ​ສັບ​ຕ່າງໆ​ກັບ Vasily​:

Vasily, [09.10.18 17:07] ທີ່ສຸດ, ກົ້ນແມ່ນຮ້ອນເພາະວ່າພວກເຂົາສ້າງຊໍ່ຂອງ abstractions, ແລະຫຼັງຈາກນັ້ນ hammered bolt ໃຫ້ເຂົາເຈົ້າ, ແລະກວມເອົາເຄື່ອງກໍາເນີດລະຫັດດ້ວຍໄມ້ຄ່ໍາ.
ດັ່ງນັ້ນ, ທໍາອິດຈາກ dock pilot.jpg
ຫຼັງຈາກນັ້ນ, ຈາກລະຫັດ dzhekichan.webp

ແນ່ນອນ, ຈາກຄົນທີ່ຄຸ້ນເຄີຍກັບ algorithms ແລະຄະນິດສາດ, ພວກເຮົາສາມາດຄາດຫວັງວ່າພວກເຂົາໄດ້ອ່ານ Aho, Ullmann, ແລະຄຸ້ນເຄີຍກັບເຄື່ອງມືທີ່ໄດ້ກາຍເປັນມາດຕະຖານໃນອຸດສາຫະກໍາຫລາຍສິບປີສໍາລັບການຂຽນຕົວລວບລວມຂໍ້ມູນ DSL ຂອງພວກເຂົາ, ແມ່ນບໍ?..

ໂດຍຜູ້ຂຽນ telegram-cli ແມ່ນ Vitaly Valtman, ຕາມທີ່ສາມາດເຂົ້າໃຈໄດ້ຈາກການປະກົດຕົວຂອງຮູບແບບ TLO ຢູ່ນອກຂອບເຂດ (cli), ສະມາຊິກຂອງທີມງານ - ໃນປັດຈຸບັນຫ້ອງສະຫມຸດສໍາລັບ TL parsing ໄດ້ຖືກຈັດສັນ. ແຍກຕ່າງຫາກ, ຄວາມປະທັບໃຈຂອງນາງແມ່ນຫຍັງ TL parser? ..

16.12 04:18 Vasily: ຂ້ອຍຄິດວ່າບາງຄົນບໍ່ໄດ້ສອນ lex+yacc
16.12 04:18 Vasily: ຂ້ອຍບໍ່ສາມາດອະທິບາຍໄດ້
16.12 04:18 Vasily: ດີ, ຫຼືພວກເຂົາໄດ້ຮັບຄ່າຈ້າງສໍາລັບຈໍານວນສາຍໃນ VK.
16.12 04:19 Vasily: 3k+ ສາຍແລະອື່ນໆ.<censored> ແທນທີ່ຈະເປັນຕົວວິເຄາະ

ບາງທີມີຂໍ້ຍົກເວັ້ນ? ໃຫ້ເບິ່ງວິທີການ ບໍ່ ນີ້ແມ່ນລູກຄ້າຢ່າງເປັນທາງການ - Telegram Desktop:

    nametype = re.match(r'([a-zA-Z.0-9_]+)(#[0-9a-f]+)?([^=]*)=s*([a-zA-Z.<>0-9_]+);', line);
    if (not nametype):
      if (not re.match(r'vector#1cb5c415 {t:Type} # [ t ] = Vector t;', line)):
         print('Bad line found: ' + line);

1100+ ແຖວໃນ Python, ສອງສາມຕົວສະແດງປົກກະຕິ + ກໍລະນີພິເສດເຊັ່ນ vector, ເຊິ່ງ, ແນ່ນອນ, ໄດ້ຖືກປະກາດໃນໂຄງການຍ້ອນວ່າມັນຄວນຈະເປັນໄປຕາມ syntax TL, ແຕ່ພວກເຂົາອີງໃສ່ syntax ນີ້ເພື່ອວິເຄາະມັນ ... ຄໍາຖາມທີ່ເກີດຂື້ນ, ເປັນຫຍັງມັນເປັນເລື່ອງມະຫັດສະຈັນ?иມັນ​ເປັນ​ຊັ້ນ​ກວ່າ​ຖ້າ​ບໍ່​ມີ​ໃຜ​ຈະ​ແຍກ​ມັນ​ຕາມ​ເອ​ກະ​ສານ​ໄດ້​?!

ໂດຍວິທີທາງການ ... ຈື່ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບການກວດສອບ CRC32 ບໍ? ດັ່ງນັ້ນ, ໃນເຄື່ອງສ້າງລະຫັດ Telegram Desktop ມີບັນຊີລາຍຊື່ຂອງຂໍ້ຍົກເວັ້ນສໍາລັບປະເພດເຫຼົ່ານັ້ນທີ່ CRC32 ທີ່ຖືກຄິດໄລ່. ບໍ່ກົງກັນ ກັບອັນທີ່ລະບຸໄວ້ໃນແຜນວາດ!

Vasily, [18.12/22 49:XNUMX] ແລະໃນທີ່ນີ້ຂ້າພະເຈົ້າຈະຄິດກ່ຽວກັບວ່າ TL ດັ່ງກ່າວແມ່ນຈໍາເປັນບໍ?
ຖ້າຂ້ອຍຕ້ອງການຂັດກັບການປະຕິບັດທາງເລືອກ, ຂ້ອຍຈະເລີ່ມໃສ່ຕົວແບ່ງແຖວ, ເຄິ່ງຫນຶ່ງຂອງຕົວວິເຄາະຈະແຕກໃນຄໍານິຍາມຫຼາຍເສັ້ນ.
tdesktop, ຢ່າງໃດກໍຕາມ, ເຊັ່ນດຽວກັນ

ຈືຂໍ້ມູນການຈຸດກ່ຽວກັບການຫນຶ່ງ liner, ພວກເຮົາຈະກັບຄືນໄປຫາມັນເລັກນ້ອຍຕໍ່ມາ.

ຕົກລົງ, telegram-cli ແມ່ນບໍ່ເປັນທາງການ, Telegram Desktop ເປັນທາງການ, ແຕ່ສິ່ງທີ່ກ່ຽວກັບຄົນອື່ນ? ໃຜຮູ້?.. ໃນລະຫັດລູກຄ້າ Android ບໍ່ມີ schema parser ເລີຍ (ເຊິ່ງເຮັດໃຫ້ເກີດຄໍາຖາມກ່ຽວກັບແຫຼ່ງເປີດ, ແຕ່ນີ້ແມ່ນສໍາລັບພາກທີສອງ), ແຕ່ມີລະຫັດຕະຫລົກຫຼາຍ, ແຕ່ມີຫຼາຍກວ່ານັ້ນໃນ ພາກສ່ວນຍ່ອຍຂ້າງລຸ່ມນີ້.

ຄໍາຖາມອື່ນໃດທີ່ serialization ຍົກຂຶ້ນມາໃນການປະຕິບັດ? ຕົວຢ່າງ, ພວກເຂົາເຈົ້າໄດ້ເຮັດຫຼາຍຢ່າງ, ແນ່ນອນ, ມີຊ່ອງບິດແລະພື້ນທີ່ທີ່ມີເງື່ອນໄຂ:

Vasily: flags.0? true
ຫມາຍຄວາມວ່າພາກສະຫນາມແມ່ນປະຈຸບັນແລະເທົ່າກັບຄວາມຈິງຖ້າທຸງຖືກຕັ້ງ

Vasily: flags.1? int
ຫມາຍຄວາມວ່າພາກສະຫນາມແມ່ນປະຈຸບັນແລະຕ້ອງໄດ້ຮັບການ deserialized

Vasily: Ass, ຢ່າກັງວົນກ່ຽວກັບສິ່ງທີ່ເຈົ້າກໍາລັງເຮັດ!
Vasily: ມີການກ່າວເຖິງບາງບ່ອນໃນເອກະສານວ່າຄວາມຈິງແມ່ນປະເພດທີ່ບໍ່ມີຄວາມຍາວ, ແຕ່ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະລວບລວມສິ່ງໃດຈາກເອກະສານຂອງພວກເຂົາ.
Vasily: ໃນການຈັດຕັ້ງປະຕິບັດແຫຼ່ງເປີດ, ນີ້ບໍ່ແມ່ນກໍລະນີ, ແຕ່ວ່າມີໄມ້ຄ້ອນແລະເຄື່ອງຮອງ.

ຈະເປັນແນວໃດກ່ຽວກັບ Telethon? ຊອກຫາລ່ວງຫນ້າກັບຫົວຂໍ້ຂອງ MTProto, ຕົວຢ່າງ - ໃນເອກະສານມີຕ່ອນດັ່ງກ່າວ, ແຕ່ເຄື່ອງຫມາຍ. % ມັນໄດ້ຖືກອະທິບາຍພຽງແຕ່ເປັນ "ທີ່ສອດຄ້ອງກັນກັບປະເພດເປົ່າ", i.e. ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້ມີຂໍ້ຜິດພາດຫຼືບາງສິ່ງບາງຢ່າງທີ່ບໍ່ມີເອກະສານ:

Vasily, [22.06.18 18:38] ໃນສະຖານທີ່ຫນຶ່ງ:

msg_container#73f1f8dc messages:vector message = MessageContainer;

ໃນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​:

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

ແລະເຫຼົ່ານີ້ແມ່ນສອງຄວາມແຕກຕ່າງໃຫຍ່, ໃນຊີວິດຈິງບາງປະເພດຂອງ vector naked ມາ

ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ໄດ້​ເຫັນ​ຄໍາ​ນິ​ຍາມ vector ເປົ່າ​ແລະ​ບໍ່​ໄດ້​ພົບ​ເຫັນ​ຫນຶ່ງ​

ການວິເຄາະແມ່ນຂຽນດ້ວຍມືໃນ telethon

ໃນແຜນວາດຂອງລາວຄໍານິຍາມໄດ້ຖືກສະແດງອອກ msg_container

ອີກເທື່ອຫນຶ່ງ, ຄໍາຖາມຍັງຄົງກ່ຽວກັບ %. ມັນບໍ່ໄດ້ຖືກອະທິບາຍ.

Vadim Goncharov, [22.06.18 19:22] ແລະໃນ tdesktop?

Vasily, [22.06.18 19:23] ແຕ່ TL parser ຂອງພວກເຂົາໃນເຄື່ອງຈັກປົກກະຕິສ່ວນຫຼາຍຈະບໍ່ກິນນີ້.

// parsed manually

TL ເປັນສິ່ງຫຍໍ້ທໍ້ທີ່ສວຍງາມ, ບໍ່ມີໃຜປະຕິບັດມັນຢ່າງສົມບູນ

ແລະ % ບໍ່ໄດ້ຢູ່ໃນສະບັບຂອງພວກເຂົາຂອງໂຄງການ

ແຕ່ໃນທີ່ນີ້ເອກະສານຂັດກັບຕົວມັນເອງ, ດັ່ງນັ້ນ idk

ມັນຖືກພົບເຫັນຢູ່ໃນໄວຍາກອນ, ພວກເຂົາສາມາດລືມພຽງແຕ່ອະທິບາຍຄວາມຫມາຍ

ເຈົ້າເຫັນເອກະສານໃນ TL, ເຈົ້າບໍ່ສາມາດຄິດໄດ້ວ່າບໍ່ມີເຄິ່ງລິດ

"ແລ້ວ, ໃຫ້ເວົ້າວ່າ," ຜູ້ອ່ານອີກຄົນຫນຶ່ງຈະເວົ້າວ່າ, "ທ່ານວິພາກວິຈານບາງສິ່ງບາງຢ່າງ, ສະນັ້ນສະແດງໃຫ້ຂ້ອຍເຫັນວ່າມັນຄວນຈະເຮັດ."

Vasily ຕອບວ່າ: "ສໍາລັບນັກວິເຄາະ, ຂ້ອຍມັກສິ່ງຕ່າງໆເຊັ່ນ

    args: /* empty */ { $$ = NULL; }
        | args arg { $$ = g_list_append( $1, $2 ); }
        ;

    arg: LC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | LC_ID ':' condition '?' type-term { $$ = tl_arg_new_cond( $1, $5, $3 ); free($3); }
            | UC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | type-term { $$ = tl_arg_new( "", $1 ); }
            | '[' LC_ID ']' { $$ = tl_arg_new_mult( "", tl_type_new( $2, TYPE_MOD_NONE ) ); }
            ;

somehow ມັກ​ມັນ​ດີກ​ວ່າ​

struct tree *parse_args4 (void) {
  PARSE_INIT (type_args4);
  struct parse so = save_parse ();
  PARSE_TRY (parse_optional_arg_def);
  if (S) {
    tree_add_child (T, S);
  } else {
    load_parse (so);
  }
  if (LEX_CHAR ('!')) {
    PARSE_ADD (type_exclam);
    EXPECT ("!");
  }
  PARSE_TRY_PES (parse_type_term);
  PARSE_OK;
}

ຫຼື

        # Regex to match the whole line
        match = re.match(r'''
            ^                  # We want to match from the beginning to the end
            ([w.]+)           # The .tl object can contain alpha_name or namespace.alpha_name
            (?:
                #             # After the name, comes the ID of the object
                ([0-9a-f]+)    # The constructor ID is in hexadecimal form
            )?                 # If no constructor ID was given, CRC32 the 'tl' to determine it

            (?:s              # After that, we want to match its arguments (name:type)
                {?             # For handling the start of the '{X:Type}' case
                w+            # The argument name will always be an alpha-only name
                :              # Then comes the separator between name:type
                [wd<>#.?!]+  # The type is slightly more complex, since it's alphanumeric and it can
                               # also have Vector<type>, flags:# and flags.0?default, plus :!X as type
                }?             # For handling the end of the '{X:Type}' case
            )*                 # Match 0 or more arguments
            s                 # Leave a space between the arguments and the equal
            =
            s                 # Leave another space between the equal and the result
            ([wd<>#.?]+)     # The result can again be as complex as any argument type
            ;$                 # Finally, the line should always end with ;
            ''', tl, re.IGNORECASE | re.VERBOSE)

ນີ້ແມ່ນ lexer ທັງຫມົດ:

    ---functions---         return FUNCTIONS;
    ---types---             return TYPES;
    [a-z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return LC_ID;
    [A-Z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return UC_ID;
    [0-9]+                  yylval.number = atoi(yytext); return NUM;
    #[0-9a-fA-F]{1,8}       yylval.number = strtol(yytext+1, NULL, 16); return ID_HASH;

    n                      /* skip new line */
    [ t]+                  /* skip spaces */
    //.*$                 /* skip comments */
    /*.**/              /* skip comments */
    .                       return (int)yytext[0];

ເຫຼົ່ານັ້ນ. ງ່າຍດາຍແມ່ນເຮັດໃຫ້ມັນອ່ອນໂຍນ.”

ໂດຍທົ່ວໄປ, ດັ່ງນັ້ນ, parser ແລະ code generator ສໍາລັບຊຸດຍ່ອຍທີ່ໃຊ້ຕົວຈິງຂອງ TL ເຫມາະເຂົ້າໄປໃນປະມານ 100 ສາຍຂອງໄວຍາກອນແລະ ~ 300 ສາຍຂອງເຄື່ອງກໍາເນີດໄຟຟ້າ (ນັບທັງຫມົດ. printລະຫັດທີ່ສ້າງຂຶ້ນ), ລວມທັງຂໍ້ມູນປະເພດ buns ສໍາລັບການ introspection ໃນແຕ່ລະຫ້ອງຮຽນ. ແຕ່ລະປະເພດ polymorphic ກາຍເປັນຫ້ອງຮຽນພື້ນຖານທີ່ບໍ່ມີຕົວຕົນຫວ່າງເປົ່າ, ແລະຜູ້ກໍ່ສ້າງໄດ້ຮັບມໍລະດົກຈາກມັນແລະມີວິທີການສໍາລັບການ serialization ແລະ deserialization.

ຂາດປະເພດໃນພາສາປະເພດ

ການພິມທີ່ເຂັ້ມແຂງເປັນສິ່ງທີ່ດີ, ບໍ່ແມ່ນບໍ? ບໍ່, ນີ້ບໍ່ແມ່ນ holivar (ເຖິງແມ່ນວ່າຂ້ອຍມັກພາສາແບບເຄື່ອນໄຫວ), ແຕ່ເປັນ postulate ພາຍໃນກອບຂອງ TL. ອີງໃສ່ມັນ, ພາສາຄວນສະຫນອງການກວດສອບທຸກປະເພດສໍາລັບພວກເຮົາ. ດີ, ບໍ່ເປັນຫຍັງ, ອາດຈະບໍ່ແມ່ນຕົວລາວເອງ, ແຕ່ການປະຕິບັດ, ແຕ່ຢ່າງຫນ້ອຍຄວນອະທິບາຍໃຫ້ເຂົາເຈົ້າ. ແລະພວກເຮົາຕ້ອງການໂອກາດປະເພດໃດ?

ກ່ອນອື່ນ ໝົດ, ຂໍ້ ຈຳ ກັດ. ນີ້ພວກເຮົາເຫັນຢູ່ໃນເອກະສານສໍາລັບການອັບໂຫລດໄຟລ໌:

ຫຼັງຈາກນັ້ນ, ເນື້ອໃນຖານສອງຂອງໄຟລ໌ໄດ້ຖືກແບ່ງອອກເປັນພາກສ່ວນ. ທຸກພາກສ່ວນຕ້ອງມີຂະໜາດດຽວກັນ ( part_size ) ແລະ​ເງື່ອນ​ໄຂ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ຈະ​ຕ້ອງ​ໄດ້​ຮັບ​:

• part_size % 1024 = 0 (ແບ່ງດ້ວຍ 1KB)
• 524288 % part_size = 0 (512KB ຕ້ອງ​ແບ່ງ​ໃຫ້​ເທົ່າ​ທຽມ​ກັນ​ໂດຍ part_size​)

ສ່ວນສຸດທ້າຍບໍ່ຈໍາເປັນຕ້ອງເຮັດໃຫ້ເງື່ອນໄຂເຫຼົ່ານີ້, ຂະຫນາດຂອງມັນແມ່ນຫນ້ອຍກວ່າ part_size.

ແຕ່ລະພາກສ່ວນຄວນມີຕົວເລກລໍາດັບ, file_part, ມີມູນຄ່າຕັ້ງແຕ່ 0 ຫາ 2,999.

ຫຼັງ​ຈາກ​ທີ່​ໄຟລ​໌​ໄດ້​ຖືກ​ແບ່ງ​ປັນ​, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ເລືອກ​ເອົາ​ວິ​ທີ​ການ​ສໍາ​ລັບ​ການ​ປະ​ຢັດ​ມັນ​ໃນ​ເຄື່ອງ​ແມ່​ຂ່າຍ​. ໃຊ້ upload.saveBigFilePart ໃນກໍລະນີທີ່ຂະຫນາດເຕັມຂອງໄຟລ໌ແມ່ນຫຼາຍກ່ວາ 10 MB ແລະ upload.saveFilePart ສໍາລັບໄຟລ໌ຂະຫນາດນ້ອຍກວ່າ.
[…] ໜຶ່ງໃນຄວາມຜິດພາດການປ້ອນຂໍ້ມູນຕໍ່ໄປນີ້ອາດຈະຖືກສົ່ງຄືນ:

• FILE_PARTS_INVALID — ຈຳນວນຊິ້ນສ່ວນບໍ່ຖືກຕ້ອງ. ມູນຄ່າບໍ່ແມ່ນລະຫວ່າງ 1..3000

ມີອັນໃດອັນໜຶ່ງຢູ່ໃນແຜນວາດບໍ? ນີ້ແມ່ນການສະແດງອອກບາງຢ່າງໂດຍໃຊ້ TL? ບໍ່. ແຕ່ຂໍໂທດ, ແມ່ນແຕ່ Turbo Pascal ຂອງພໍ່ຕູ້ກໍສາມາດອະທິບາຍປະເພດຕ່າງໆໄດ້ ຊ່ວງ. ແລະລາວຮູ້ອີກຢ່າງຫນຶ່ງ, ປະຈຸບັນເປັນທີ່ຮູ້ຈັກກັນດີໃນນາມ enum - ປະ​ເພດ​ປະ​ກອບ​ດ້ວຍ enumeration ຂອງ​ຈໍາ​ນວນ​ຄົງ​ທີ່ (ນ້ອຍ​) ຂອງ​ຄ່າ​. ໃນພາສາເຊັ່ນ C - ຕົວເລກ, ໃຫ້ສັງເກດວ່າມາຮອດປະຈຸບັນພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບປະເພດເທົ່ານັ້ນ ຕົວເລກ. ແຕ່ຍັງມີ arrays, strings ... ຕົວຢ່າງ, ມັນຈະເປັນການດີທີ່ຈະພັນລະນາວ່າ string ນີ້ມີພຽງແຕ່ເບີໂທລະສັບເທົ່ານັ້ນ, ແມ່ນບໍ?

ບໍ່ມີອັນນີ້ຢູ່ໃນ TL. ແຕ່ມີ, ສໍາລັບຕົວຢ່າງ, ໃນ JSON Schema. ແລະຖ້າຜູ້ອື່ນອາດຈະໂຕ້ຖຽງກ່ຽວກັບການແບ່ງສ່ວນຂອງ 512 KB, ວ່ານີ້ຍັງຕ້ອງໄດ້ຮັບການກວດສອບລະຫັດ, ຫຼັງຈາກນັ້ນໃຫ້ແນ່ໃຈວ່າລູກຄ້າພຽງແຕ່. ບໍ່​ສາ​ມາດ ສົ່ງຕົວເລກອອກຈາກຂອບເຂດ 1..3000 (ແລະຄວາມຜິດພາດທີ່ສອດຄ້ອງກັນບໍ່ສາມາດເກີດຂຶ້ນໄດ້) ມັນເປັນໄປໄດ້, ບໍ່ແມ່ນບໍ? ..

ໂດຍວິທີທາງການ, ກ່ຽວກັບຄວາມຜິດພາດແລະຄ່າກັບຄືນ. ເຖິງແມ່ນວ່າຜູ້ທີ່ໄດ້ເຮັດວຽກກັບ TL ເຮັດໃຫ້ມົວຕາຂອງພວກເຂົາ - ມັນບໍ່ຮຸ່ງລຸນໃນທັນທີ ແຕ່​ລະ​ອັນ ຟັງຊັນໃນ TL ສາມາດກັບຄືນມາບໍ່ພຽງແຕ່ປະເພດຜົນຕອບແທນທີ່ອະທິບາຍ, ແຕ່ຍັງເປັນຂໍ້ຜິດພາດ. ແຕ່ນີ້ບໍ່ສາມາດ deduced ໃນທາງໃດກໍ່ຕາມໂດຍໃຊ້ TL ຕົວຂອງມັນເອງ. ແນ່ນອນ, ມັນຈະແຈ້ງແລ້ວແລະບໍ່ຈໍາເປັນຕ້ອງມີສິ່ງໃດໃນການປະຕິບັດ (ເຖິງແມ່ນວ່າໃນຄວາມເປັນຈິງ, RPC ສາມາດເຮັດໄດ້ໃນວິທີທີ່ແຕກຕ່າງກັນ, ພວກເຮົາຈະກັບຄືນມາໃນພາຍຫລັງ) - ແຕ່ສິ່ງທີ່ກ່ຽວກັບຄວາມບໍລິສຸດຂອງແນວຄວາມຄິດຂອງຄະນິດສາດຂອງປະເພດບໍ່ມີຕົວຕົນ. ຈາກ​ໂລກ​ສະ​ຫວັນ​?.. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເອົາ​ຂຶ້ນ tug - ດັ່ງ​ນັ້ນ​ຄໍາ​ວ່າ​ມັນ​.

ແລະສຸດທ້າຍ, ແມ່ນຫຍັງກ່ຽວກັບການອ່ານ? ດີ, ໂດຍທົ່ວໄປ, ຂ້ອຍຕ້ອງການ ຄໍາອະທິບາຍ ມັນຖືກຕ້ອງໃນ schema (ໃນ JSON schema, ອີກເທື່ອຫນຶ່ງ, ມັນແມ່ນ), ແຕ່ຖ້າທ່ານມີຄວາມເຄັ່ງຕຶງກັບມັນແລ້ວ, ຈະເປັນແນວໃດກ່ຽວກັບດ້ານປະຕິບັດ - ຢ່າງຫນ້ອຍເລັກນ້ອຍທີ່ຈະເບິ່ງຄວາມແຕກຕ່າງໃນລະຫວ່າງການປັບປຸງ? ເບິ່ງສໍາລັບຕົວທ່ານເອງທີ່ ຕົວຢ່າງທີ່ແທ້ຈິງ:

-channelFull#76af5481 flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;
+channelFull#1c87a71a flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true can_view_stats:flags.12?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int online_count:flags.13?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;

ຫຼື

-message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;
+message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;

ມັນຂຶ້ນກັບທຸກຄົນ, ແຕ່ GitHub, ສໍາລັບການຍົກຕົວຢ່າງ, ປະຕິເສດທີ່ຈະເນັ້ນການປ່ຽນແປງພາຍໃນເສັ້ນຍາວດັ່ງກ່າວ. ເກມ "ຊອກຫາ 10 ຄວາມແຕກຕ່າງ", ແລະສິ່ງທີ່ສະຫມອງເຫັນທັນທີແມ່ນວ່າຈຸດເລີ່ມຕົ້ນແລະຈຸດສິ້ນສຸດໃນທັງສອງຕົວຢ່າງແມ່ນຄືກັນ, ທ່ານຈໍາເປັນຕ້ອງອ່ານທີ່ຫນ້າເບື່ອຫນ່າຍໃນກາງ ... ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ນີ້ບໍ່ແມ່ນພຽງແຕ່ໃນທິດສະດີ, ແຕ່ຢ່າງດຽວກັບສາຍຕາ ເປື້ອນ ແລະ sloppy.

ໂດຍວິທີທາງການ, ກ່ຽວກັບຄວາມບໍລິສຸດຂອງທິດສະດີ. ເປັນຫຍັງພວກເຮົາຕ້ອງການຊ່ອງຂໍ້ມູນນ້ອຍ? ມັນເບິ່ງຄືວ່າພວກເຂົາບໍ່ ມີກິ່ນຫອມ ບໍ່ດີຈາກທັດສະນະຂອງທິດສະດີປະເພດ? ຄໍາອະທິບາຍສາມາດເຫັນໄດ້ໃນສະບັບກ່ອນຫນ້າຂອງແຜນວາດ. ທໍາອິດ, ແມ່ນແລ້ວ, ມັນເປັນແນວໃດ, ສໍາລັບທຸກໆການຈາມ, ປະເພດໃຫມ່ໄດ້ຖືກສ້າງຂື້ນ. rudiments ເຫຼົ່ານີ້ຍັງມີຢູ່ໃນຮູບແບບນີ້, ສໍາລັບການຍົກຕົວຢ່າງ:

storage.fileUnknown#aa963b05 = storage.FileType;
storage.filePartial#40bc6f52 = storage.FileType;
storage.fileJpeg#7efe0e = storage.FileType;
storage.fileGif#cae1aadf = storage.FileType;
storage.filePng#a4f63c0 = storage.FileType;
storage.filePdf#ae1e508d = storage.FileType;
storage.fileMp3#528a0677 = storage.FileType;
storage.fileMov#4b09ebbc = storage.FileType;
storage.fileMp4#b3cea0e4 = storage.FileType;
storage.fileWebp#1081464c = storage.FileType;

ແຕ່ໃນປັດຈຸບັນຈິນຕະນາການ, ຖ້າທ່ານມີ 5 ພາກສະຫນາມທາງເລືອກໃນໂຄງສ້າງຂອງທ່ານ, ຫຼັງຈາກນັ້ນທ່ານຈະຕ້ອງການ 32 ປະເພດສໍາລັບທາງເລືອກທີ່ເປັນໄປໄດ້ທັງຫມົດ. ການລະເບີດປະສົມ. ດັ່ງນັ້ນ, ຄວາມບໍລິສຸດໄປເຊຍກັນຂອງທິດສະດີ TL ໄດ້ແຕກຫັກອີກເທື່ອຫນຶ່ງຕໍ່ກັບກົ້ນຂອງທາດເຫຼັກສຽງໂຫວດທັງຫມົດຂອງຄວາມເປັນຈິງ harsh ຂອງ serialization.

ນອກຈາກນັ້ນ, ໃນບາງບ່ອນ, ຄົນເຫຼົ່ານີ້ເອງລະເມີດ typology ຂອງຕົນເອງ. ຕົວຢ່າງ, ໃນ MTProto (ບົດຕໍ່ໄປ) ການຕອບສະຫນອງສາມາດຖືກບີບອັດໂດຍ Gzip, ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ - ຍົກເວັ້ນວ່າຊັ້ນແລະວົງຈອນຖືກລະເມີດ. ອີກເທື່ອຫນຶ່ງ, ມັນບໍ່ແມ່ນ RpcResult ຕົວຂອງມັນເອງທີ່ຖືກເກັບກ່ຽວ, ແຕ່ເນື້ອໃນຂອງມັນ. ແລ້ວ, ເປັນຫຍັງເຮັດແບບນີ້?.. ຂ້ອຍຕ້ອງຕັດເປັນໄມ້ຄ້ອນເພື່ອການບີບອັດຈະເຮັດວຽກໄດ້ທຸກບ່ອນ.

ຫຼືຕົວຢ່າງອື່ນ, ເມື່ອພວກເຮົາຄົ້ນພົບຂໍ້ຜິດພາດ - ມັນຖືກສົ່ງ InputPeerUser ແທນທີ່ຈະ InputUser. ຫຼືໃນທາງກັບກັນ. ແຕ່ມັນເຮັດວຽກ! ນັ້ນແມ່ນ, ເຄື່ອງແມ່ຂ່າຍບໍ່ໄດ້ສົນໃຈປະເພດ. ນີ້ເປັນໄປໄດ້ແນວໃດ? ຄໍາຕອບອາດຈະຖືກມອບໃຫ້ພວກເຮົາໂດຍຊິ້ນສ່ວນລະຫັດຈາກ telegram-cli:

  if (tgl_get_peer_type (E->id) != TGL_PEER_CHANNEL || (C && (C->flags & TGLCHF_MEGAGROUP))) {
    out_int (CODE_messages_get_history);
    out_peer_id (TLS, E->id);
  } else {    
    out_int (CODE_channels_get_important_history);

    out_int (CODE_input_channel);
    out_int (tgl_get_peer_id (E->id));
    out_long (E->id.access_hash);
  }
  out_int (E->max_id);
  out_int (E->offset);
  out_int (E->limit);
  out_int (0);
  out_int (0);

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ນີ້ແມ່ນບ່ອນທີ່ serialization ແມ່ນເຮັດ ດ້ວຍຕົນເອງ, ບໍ່​ໄດ້​ສ້າງ​ລະ​ຫັດ​! ບາງທີເຊີບເວີຖືກປະຕິບັດໃນລັກສະນະທີ່ຄ້າຍຄືກັນ?.. ໃນຫຼັກການ, ນີ້ຈະເຮັດວຽກຖ້າເຮັດຄັ້ງດຽວ, ແຕ່ມັນຈະໄດ້ຮັບການສະຫນັບສະຫນູນແນວໃດຕໍ່ມາໃນລະຫວ່າງການປັບປຸງ? ນີ້ແມ່ນວ່າເປັນຫຍັງໂຄງການໄດ້ຖືກປະດິດ? ແລະໃນທີ່ນີ້ພວກເຮົາກ້າວໄປສູ່ຄໍາຖາມຕໍ່ໄປ.

ຮຸ່ນ. ຊັ້ນ

ເປັນຫຍັງສະບັບ schematic ຖືກເອີ້ນວ່າຊັ້ນພຽງແຕ່ສາມາດຄາດເດົາໄດ້ໂດຍອີງໃສ່ປະຫວັດສາດຂອງ schematics ທີ່ຈັດພີມມາ. ປາກົດຂື້ນ, ໃນຕອນທໍາອິດຜູ້ຂຽນຄິດວ່າສິ່ງພື້ນຖານສາມາດເຮັດໄດ້ໂດຍໃຊ້ໂຄງການທີ່ບໍ່ປ່ຽນແປງ, ແລະພຽງແຕ່ບ່ອນທີ່ມີຄວາມຈໍາເປັນ, ສໍາລັບການຮ້ອງຂໍສະເພາະ, ຊີ້ໃຫ້ເຫັນວ່າພວກເຂົາຖືກປະຕິບັດໂດຍໃຊ້ສະບັບທີ່ແຕກຕ່າງກັນ. ໃນຫຼັກການ, ເຖິງແມ່ນວ່າມັນບໍ່ແມ່ນຄວາມຄິດທີ່ບໍ່ດີ, ຮູບແບບໃຫມ່ຈະຖືກ "ປະສົມ", ຍ້ອນວ່າມັນເປັນ, ຊັ້ນເທິງຂອງເກົ່າ. ແຕ່​ໃຫ້​ເຮົາ​ເບິ່ງ​ວ່າ​ມັນ​ເຮັດ​ໄດ້​ແນວ​ໃດ. ແທ້ຈິງແລ້ວ, ຂ້ອຍບໍ່ສາມາດເບິ່ງມັນຕັ້ງແຕ່ເລີ່ມຕົ້ນ - ມັນເປັນເລື່ອງຕະຫລົກ, ແຕ່ແຜນວາດຂອງຊັ້ນພື້ນຖານພຽງແຕ່ບໍ່ມີ. ຊັ້ນເລີ່ມຕົ້ນດ້ວຍ 2. ເອກະສານບອກພວກເຮົາກ່ຽວກັບຄຸນສົມບັດພິເສດຂອງ TL:

ຖ້າລູກຄ້າສະຫນັບສະຫນູນ Layer 2, ຫຼັງຈາກນັ້ນຕ້ອງໃຊ້ constructor ຕໍ່ໄປນີ້:

invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;

ໃນການປະຕິບັດ, ນີ້ຫມາຍຄວາມວ່າກ່ອນທີ່ຈະທຸກການໂທ API, int ທີ່ມີຄ່າ 0x289dd1f6 ຕ້ອງຖືກເພີ່ມໃສ່ກ່ອນເລກວິທີ.

ສຽງປົກກະຕິ. ແຕ່ສິ່ງທີ່ເກີດຂຶ້ນຕໍ່ໄປ? ຫຼັງຈາກນັ້ນປາກົດ

invokeWithLayer3#b7475268 query:!X = X;

ດັ່ງນັ້ນແມ່ນຫຍັງຕໍ່ໄປ? ຕາມທີ່ເຈົ້າອາດຈະເດົາ,

invokeWithLayer4#dea0d430 query:!X = X;

ຕະຫລົກ? ບໍ່, ມັນໄວເກີນໄປທີ່ຈະຫົວເລາະ, ຄິດກ່ຽວກັບຄວາມຈິງທີ່ວ່າ ທຸກ ການຮ້ອງຂໍຈາກຊັ້ນອື່ນຕ້ອງໄດ້ຮັບການຫໍ່ດ້ວຍປະເພດພິເສດດັ່ງກ່າວ - ຖ້າພວກມັນທັງຫມົດແຕກຕ່າງກັນສໍາລັບທ່ານ, ທ່ານສາມາດຈໍາແນກພວກມັນໄດ້ແນວໃດ? ແລະການເພີ່ມພຽງແຕ່ 4 bytes ຢູ່ທາງຫນ້າແມ່ນວິທີການທີ່ມີປະສິດທິພາບທີ່ສວຍງາມ. ດັ່ງນັ້ນ,

invokeWithLayer5#417a57ae query:!X = X;

ແຕ່ມັນເປັນທີ່ຊັດເຈນວ່າຫຼັງຈາກໃນຂະນະທີ່ນີ້ຈະກາຍເປັນບາງປະເພດຂອງ bacchanalia. ແລະ​ການ​ແກ້​ໄຂ​ມາ​:

ອັບເດດ: ເລີ່ມຕົ້ນດ້ວຍຊັ້ນ 9, ວິທີການຜູ້ຊ່ວຍ invokeWithLayerN ສາ​ມາດ​ນໍາ​ໃຊ້​ພຽງ​ແຕ່​ຮ່ວມ​ກັບ​ initConnection

ໂຫ້ຍ! ຫຼັງຈາກ 9 ຮຸ່ນ, ໃນທີ່ສຸດພວກເຮົາໄດ້ມາຮອດສິ່ງທີ່ເຮັດໃນໂປໂຕຄອນອິນເຕີເນັດກັບຄືນໄປບ່ອນໃນ 80s - ຕົກລົງກັບສະບັບຫນຶ່ງຄັ້ງໃນຕອນເລີ່ມຕົ້ນຂອງການເຊື່ອມຕໍ່!

ແລ້ວແມ່ນຫຍັງຕໍ່ໄປ?..

invokeWithLayer10#39620c41 query:!X = X;
...
invokeWithLayer18#1c900537 query:!X = X;

ແຕ່ດຽວນີ້ເຈົ້າຍັງສາມາດຫົວໄດ້. ພຽງແຕ່ຫຼັງຈາກອີກ 9 ຊັ້ນ, ຜູ້ກໍ່ສ້າງທົ່ວໄປທີ່ມີຕົວເລກສະບັບໄດ້ຖືກເພີ່ມ, ເຊິ່ງຈໍາເປັນຕ້ອງໄດ້ໂທຫາພຽງແຕ່ຄັ້ງດຽວໃນຕອນເລີ່ມຕົ້ນຂອງການເຊື່ອມຕໍ່, ແລະຄວາມ ໝາຍ ຂອງຊັ້ນຕ່າງໆເບິ່ງຄືວ່າໄດ້ຫາຍໄປ, ດຽວນີ້ມັນເປັນພຽງແຕ່ສະບັບທີ່ມີເງື່ອນໄຂ, ເຊັ່ນ: ຢູ່ທົ່ວທຸກແຫ່ງ. ບັນຫາຖືກແກ້ໄຂ.

ຢ່າງ​ແນ່​ນອນ?..

Vasily, [16.07.18 14:01] ເຖິງແມ່ນວ່າໃນວັນສຸກຂ້າພະເຈົ້າຄິດວ່າ:
teleserver ສົ່ງເຫດການໂດຍບໍ່ມີການຮ້ອງຂໍ. ການຮ້ອງຂໍຕ້ອງຖືກຫໍ່ຢູ່ໃນ InvokeWithLayer. ເຊີບເວີບໍ່ໄດ້ຫໍ່ການປັບປຸງ; ບໍ່ມີໂຄງສ້າງສໍາລັບການຫໍ່ຄໍາຕອບແລະການປັບປຸງ.

ເຫຼົ່ານັ້ນ. ລູກຄ້າບໍ່ສາມາດລະບຸຊັ້ນທີ່ລາວຕ້ອງການການປັບປຸງ

Vadim Goncharov, [16.07.18 14:02] ບໍ່ແມ່ນ InvokeWithLayer ເປັນໄມ້ຄ້ອນໃນຫຼັກການບໍ?

Vasily, [16.07.18 14:02] ນີ້ແມ່ນວິທີດຽວ

Vadim Goncharov, [16.07.18 14:02] ເຊິ່ງເປັນສິ່ງຈໍາເປັນຫມາຍຄວາມວ່າການຕົກລົງໃນຊັ້ນໃນຕອນຕົ້ນຂອງກອງປະຊຸມ

ໂດຍວິທີທາງການ, ມັນປະຕິບັດຕາມວ່າລູກຄ້າ downgrade ບໍ່ໄດ້ຖືກສະຫນອງໃຫ້

ການປັບປຸງ, i.e. ປະເພດ Updates ໃນໂຄງການ, ນີ້ແມ່ນສິ່ງທີ່ເຄື່ອງແມ່ຂ່າຍສົ່ງໄປຫາລູກຄ້າບໍ່ແມ່ນການຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍ API, ແຕ່ເປັນເອກະລາດໃນເວລາທີ່ເຫດການເກີດຂຶ້ນ. ນີ້ແມ່ນຫົວຂໍ້ທີ່ສັບສົນທີ່ຈະໄດ້ຮັບການປຶກສາຫາລືໃນຂໍ້ຄວາມອື່ນ, ແຕ່ສໍາລັບໃນປັດຈຸບັນມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮູ້ວ່າເຄື່ອງແມ່ຂ່າຍຈະຊ່ວຍປະຢັດການປັບປຸງເຖິງແມ່ນວ່າໃນເວລາທີ່ລູກຄ້າ offline.

ດັ່ງນັ້ນ, ຖ້າທ່ານປະຕິເສດການຫໍ່ ແຕ່ລະຄົນ ຊຸດເພື່ອຊີ້ບອກສະບັບຂອງມັນ, ເຫດຜົນນີ້ນໍາໄປສູ່ບັນຫາທີ່ເປັນໄປໄດ້ຕໍ່ໄປນີ້:

• ເຊີບເວີຈະສົ່ງການອັບເດດໃຫ້ກັບລູກຄ້າກ່ອນທີ່ລູກຄ້າຈະແຈ້ງໃຫ້ລູກຄ້າຮູ້ວ່າມັນຮອງຮັບລຸ້ນໃດ
• ຂ້ອຍຄວນເຮັດແນວໃດຫຼັງຈາກການຍົກລະດັບລູກຄ້າ?
• ຜູ້ທີ່ ຮັບປະກັນວ່າຄວາມຄິດເຫັນຂອງເຄື່ອງແມ່ຂ່າຍກ່ຽວກັບເລກຊັ້ນຈະບໍ່ປ່ຽນແປງໃນລະຫວ່າງຂະບວນການບໍ?

ທ່ານຄິດວ່ານີ້ແມ່ນການຄາດເດົາທາງທິດສະດີຢ່າງແທ້ຈິງ, ແລະໃນທາງປະຕິບັດມັນບໍ່ສາມາດເກີດຂຶ້ນໄດ້, ເພາະວ່າເຄື່ອງແມ່ຂ່າຍຖືກຂຽນຢ່າງຖືກຕ້ອງ (ຢ່າງຫນ້ອຍ, ມັນຖືກທົດສອບດີ)? ຮາ! ບໍ່ວ່າມັນເປັນແນວໃດ!

ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາດໍາເນີນການໃນເດືອນສິງຫາ. ໃນວັນທີ 14 ສິງຫາ, ມີຂໍ້ຄວາມວ່າບາງສິ່ງບາງຢ່າງໄດ້ຖືກປັບປຸງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງ Telegram ... ແລະຫຼັງຈາກນັ້ນຢູ່ໃນບັນທຶກ:

2019-08-15 09:28:35.880640 MSK warn  main: ANON:87: unknown object type: 0x80d182d1 at TL/Object.pm line 213.
2019-08-15 09:28:35.751899 MSK warn  main: ANON:87: unknown object type: 0xb5223b0f at TL/Object.pm line 213.

ແລະຫຼັງຈາກນັ້ນຫຼາຍ megabytes ຂອງ stack traces (ດີ, ໃນເວລາດຽວກັນ, ການຕັດໄມ້ໄດ້ຖືກແກ້ໄຂ). ຫຼັງຈາກທີ່ທັງຫມົດ, ຖ້າບາງສິ່ງບາງຢ່າງບໍ່ຖືກຮັບຮູ້ໃນ TL ຂອງທ່ານ, ມັນເປັນຄູ່ໂດຍລາຍເຊັນ, ຕໍ່ໄປອີກແລ້ວ. ທັງໝົດ ໄປ, ການຖອດລະຫັດຈະກາຍເປັນເປັນໄປບໍ່ໄດ້. ເຈົ້າຄວນເຮັດແນວໃດໃນສະຖານະການດັ່ງກ່າວ?

ດີ, ສິ່ງທໍາອິດທີ່ຢູ່ໃນໃຈຂອງໃຜຜູ້ຫນຶ່ງແມ່ນເພື່ອຕັດການເຊື່ອມຕໍ່ແລະພະຍາຍາມອີກເທື່ອຫນຶ່ງ. ບໍ່ໄດ້ຊ່ວຍ. ພວກເຮົາ google CRC32 - ເຫຼົ່ານີ້ໄດ້ກາຍເປັນວັດຖຸຈາກໂຄງການ 73, ເຖິງແມ່ນວ່າພວກເຮົາໄດ້ເຮັດວຽກຢູ່ໃນ 82. ພວກເຮົາເບິ່ງຢ່າງລະມັດລະວັງໃນບັນທຶກ - ມີຕົວລະບຸຈາກສອງໂຄງການທີ່ແຕກຕ່າງກັນ!

ບາງທີບັນຫາແມ່ນຢູ່ໃນລູກຄ້າທີ່ບໍ່ເປັນທາງການຂອງພວກເຮົາບໍ? ບໍ່, ພວກເຮົາເປີດຕົວ Telegram Desktop 1.2.17 (ສະບັບທີ່ສະຫນອງໃຫ້ຢູ່ໃນຈໍານວນການແຈກຢາຍ Linux), ມັນຂຽນໃສ່ບັນທຶກການຍົກເວັ້ນ: MTP Unexpected type id #b5223b0f ອ່ານໃນ MTPMessageMedia…

ກູໂກໄດ້ສະແດງໃຫ້ເຫັນວ່າບັນຫາທີ່ຄ້າຍຄືກັນໄດ້ເກີດຂຶ້ນແລ້ວກັບຫນຶ່ງໃນລູກຄ້າທີ່ບໍ່ເປັນທາງການ, ແຕ່ຫຼັງຈາກນັ້ນຕົວເລກຮຸ່ນແລະ, ຕາມນັ້ນ, ການສົມມຸດຕິຖານແມ່ນແຕກຕ່າງກັນ ...

ດັ່ງນັ້ນພວກເຮົາຄວນເຮັດແນວໃດ? Vasily ແລະຂ້ອຍແຍກກັນ: ລາວພະຍາຍາມປັບປຸງວົງຈອນເປັນ 91, ຂ້ອຍຕັດສິນໃຈລໍຖ້າສອງສາມມື້ແລະພະຍາຍາມ 73. ທັງສອງວິທີໄດ້ຜົນ, ແຕ່ຍ້ອນວ່າພວກມັນເປັນ empirical, ມັນບໍ່ມີຄວາມເຂົ້າໃຈກ່ຽວກັບຈໍານວນຮຸ່ນຂຶ້ນຫຼືລົງທີ່ທ່ານຕ້ອງການ. ເພື່ອເຕັ້ນໄປຫາ, ຫຼືທ່ານຕ້ອງການລໍຖ້າດົນປານໃດ.

ຕໍ່ມາຂ້ອຍສາມາດສ້າງສະຖານະການໃຫມ່ໄດ້: ພວກເຮົາເປີດຕົວລູກຄ້າ, ປິດມັນ, ລວບລວມວົງຈອນກັບຊັ້ນອື່ນ, ເລີ່ມຕົ້ນໃຫມ່, ຈັບບັນຫາອີກເທື່ອຫນຶ່ງ, ກັບຄືນໄປຫາອັນທີ່ຜ່ານມາ - oops, ບໍ່ມີການປ່ຽນວົງຈອນແລະລູກຄ້າ restart ສໍາລັບ ສອງສາມນາທີຈະຊ່ວຍໄດ້. ທ່ານຈະໄດ້ຮັບການປະສົມປະສານຂອງໂຄງສ້າງຂໍ້ມູນຈາກຊັ້ນຕ່າງໆ.

ຄໍາອະທິບາຍ? ດັ່ງທີ່ທ່ານສາມາດຄາດເດົາໄດ້ຈາກອາການທາງອ້ອມຕ່າງໆ, ເຄື່ອງແມ່ຂ່າຍປະກອບດ້ວຍຫຼາຍຂະບວນການຂອງປະເພດຕ່າງໆໃນເຄື່ອງຈັກທີ່ແຕກຕ່າງກັນ. ສ່ວນຫຼາຍອາດຈະ, ເຄື່ອງແມ່ຂ່າຍທີ່ຮັບຜິດຊອບສໍາລັບການ "buffering" ເຂົ້າໄປໃນແຖວສິ່ງທີ່ຜູ້ນໍາຂອງມັນໃຫ້ມັນ, ແລະພວກເຂົາໃຫ້ມັນຢູ່ໃນໂຄງການທີ່ມີຢູ່ໃນເວລາຂອງການຜະລິດ. ແລະຈົນກ່ວາແຖວນີ້ "ເນົ່າເປື່ອຍ", ບໍ່ມີຫຍັງສາມາດເຮັດໄດ້ກ່ຽວກັບມັນ.

ບາງທີ ... ແຕ່ນີ້ແມ່ນ crutch ຂີ້ຮ້າຍ?!.. ບໍ່, ກ່ອນທີ່ຈະຄິດກ່ຽວກັບແນວຄວາມຄິດ Crazy, ໃຫ້ເບິ່ງລະຫັດຂອງລູກຄ້າຢ່າງເປັນທາງການ. ໃນ​ສະ​ບັບ Android ພວກ​ເຮົາ​ບໍ່​ໄດ້​ຊອກ​ຫາ TL parser ໃດ​, ແຕ່​ວ່າ​ພວກ​ເຮົາ​ຊອກ​ຫາ​ໄຟລ​໌ hefty (GitHub ປະ​ຕິ​ເສດ​ທີ່​ຈະ​ສໍາ​ພັດ​ມັນ​) ກັບ (de​)serialization​. ນີ້ແມ່ນຕົວຢ່າງຂອງລະຫັດ:

public static class TL_message_layer68 extends TL_message {
    public static int constructor = 0xc09be45f;
//...
//еще пачка подобных
//...
    public static class TL_message_layer47 extends TL_message {
        public static int constructor = 0xc992e15c;
        public static Message TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
            Message result = null;
            switch (constructor) {
                case 0x1d86f70e:
                    result = new TL_messageService_old2();
                    break;
                case 0xa7ab1991:
                    result = new TL_message_old3();
                    break;
                case 0xc3060325:
                    result = new TL_message_old4();
                    break;
                case 0x555555fa:
                    result = new TL_message_secret();
                    break;
                case 0x555555f9:
                    result = new TL_message_secret_layer72();
                    break;
                case 0x90dddc11:
                    result = new TL_message_layer72();
                    break;
                case 0xc09be45f:
                    result = new TL_message_layer68();
                    break;
                case 0xc992e15c:
                    result = new TL_message_layer47();
                    break;
                case 0x5ba66c13:
                    result = new TL_message_old7();
                    break;
                case 0xc06b9607:
                    result = new TL_messageService_layer48();
                    break;
                case 0x83e5de54:
                    result = new TL_messageEmpty();
                    break;
                case 0x2bebfa86:
                    result = new TL_message_old6();
                    break;
                case 0x44f9b43d:
                    result = new TL_message_layer104();
                    break;
                case 0x1c9b1027:
                    result = new TL_message_layer104_2();
                    break;
                case 0xa367e716:
                    result = new TL_messageForwarded_old2(); //custom
                    break;
                case 0x5f46804:
                    result = new TL_messageForwarded_old(); //custom
                    break;
                case 0x567699b3:
                    result = new TL_message_old2(); //custom
                    break;
                case 0x9f8d60bb:
                    result = new TL_messageService_old(); //custom
                    break;
                case 0x22eb6aba:
                    result = new TL_message_old(); //custom
                    break;
                case 0x555555F8:
                    result = new TL_message_secret_old(); //custom
                    break;
                case 0x9789dac4:
                    result = new TL_message_layer104_3();
                    break;

ຫຼື

    boolean fixCaption = !TextUtils.isEmpty(message) &&
    (media instanceof TLRPC.TL_messageMediaPhoto_old ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer68 ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer74 ||
     media instanceof TLRPC.TL_messageMediaDocument_old ||
     media instanceof TLRPC.TL_messageMediaDocument_layer68 ||
     media instanceof TLRPC.TL_messageMediaDocument_layer74)
    && message.startsWith("-1");

ຮືມ... ເບິ່ງຄືປ່າ. ແຕ່, ອາດຈະເປັນ, ນີ້ແມ່ນລະຫັດທີ່ສ້າງຂຶ້ນ, ແລ້ວ okay?.. ແຕ່ແນ່ນອນວ່າມັນສະຫນັບສະຫນູນທຸກລຸ້ນ! ແທ້ຈິງແລ້ວ, ມັນບໍ່ຈະແຈ້ງວ່າເປັນຫຍັງທຸກສິ່ງທຸກຢ່າງຈຶ່ງປະສົມກັນ, ການສົນທະນາລັບ, ແລະທຸກປະເພດ _old7 ເບິ່ງຄືວ່າບໍ່ຄືກັບການຜະລິດເຄື່ອງຈັກ ... ແນວໃດກໍ່ຕາມ, ສ່ວນຫຼາຍຂ້ອຍຖືກພັດອອກໄປ

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

ຜູ້ຊາຍ, ເຈົ້າຍັງບໍ່ສາມາດຕັດສິນໃຈວ່າແມ່ນຫຍັງຢູ່ໃນຊັ້ນດຽວ?! ແລ້ວ, ໂອເຄ, ໃຫ້ເວົ້າວ່າ "ສອງ" ຖືກປ່ອຍອອກມາດ້ວຍຄວາມຜິດພາດ, ດີ, ມັນເກີດຂຶ້ນ, ແຕ່ສາມ? .. ທັນທີ, rake ດຽວກັນອີກເທື່ອຫນຶ່ງ? ອັນນີ້ມັນເປັນຮູບລາມົກອັນໃດ, ຂໍໂທດ..?

ໃນລະຫັດແຫຼ່ງຂອງ Telegram Desktop, ໂດຍວິທີທາງການ, ສິ່ງທີ່ຄ້າຍຄືກັນເກີດຂື້ນ - ຖ້າເປັນດັ່ງນັ້ນ, ຫຼາຍຄໍາຫມັ້ນສັນຍາຕິດຕໍ່ກັນກັບໂຄງການບໍ່ໄດ້ປ່ຽນຕົວເລກຊັ້ນຂອງມັນ, ແຕ່ແກ້ໄຂບາງສິ່ງບາງຢ່າງ. ໃນເງື່ອນໄຂທີ່ບໍ່ມີແຫຼ່ງຂໍ້ມູນຢ່າງເປັນທາງການສໍາລັບໂຄງການ, ມັນສາມາດມາຈາກໃສ, ຍົກເວັ້ນລະຫັດແຫຼ່ງຂອງລູກຄ້າຢ່າງເປັນທາງການ? ແລະຖ້າທ່ານເອົາມັນຈາກບ່ອນນັ້ນ, ທ່ານບໍ່ສາມາດແນ່ໃຈວ່າໂຄງການແມ່ນຖືກຕ້ອງຫມົດຈົນກວ່າທ່ານຈະທົດສອບວິທີການທັງຫມົດ.

ນີ້ຍັງສາມາດທົດສອບໄດ້ແນວໃດ? ຂ້າ​ພະ​ເຈົ້າ​ຫວັງ​ວ່າ fans ຂອງ​ຫນ່ວຍ​ງານ​, ການ​ທົດ​ສອບ​ປະ​ໂຫຍດ​ແລະ​ອື່ນໆ​ຈະ​ແບ່ງ​ປັນ​ໃນ​ຄໍາ​ເຫັນ​.

ຕົກລົງ, ໃຫ້ເບິ່ງລະຫັດອື່ນ:

public static class TL_folders_deleteFolder extends TLObject {
    public static int constructor = 0x1c295881;

    public int folder_id;

    public TLObject deserializeResponse(AbstractSerializedData stream, int constructor, boolean exception) {
        return Updates.TLdeserialize(stream, constructor, exception);
    }

    public void serializeToStream(AbstractSerializedData stream) {
        stream.writeInt32(constructor);
        stream.writeInt32(folder_id);
    }
}

//manually created

//RichText start
public static abstract class RichText extends TLObject {
    public String url;
    public long webpage_id;
    public String email;
    public ArrayList<RichText> texts = new ArrayList<>();
    public RichText parentRichText;

    public static RichText TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
        RichText result = null;
        switch (constructor) {
            case 0x1ccb966a:
                result = new TL_textPhone();
                break;
            case 0xc7fb5e01:
                result = new TL_textSuperscript();
                break;

ຄໍາເຫັນນີ້ "ສ້າງດ້ວຍຕົນເອງ" ແນະນໍາວ່າພຽງແຕ່ສ່ວນຫນຶ່ງຂອງໄຟລ໌ນີ້ໄດ້ຖືກຂຽນດ້ວຍຕົນເອງ (ທ່ານສາມາດຈິນຕະນາການຝັນຮ້າຍການບໍາລຸງຮັກສາທັງຫມົດບໍ?), ແລະສ່ວນທີ່ເຫຼືອແມ່ນຜະລິດໂດຍເຄື່ອງຈັກ. ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກນັ້ນຄໍາຖາມອື່ນເກີດຂຶ້ນ - ວ່າແຫຼ່ງຂໍ້ມູນທີ່ມີຢູ່ ບໍ່ສົມບູນ (a la GPL blobs ໃນ Linux kernel), ແຕ່ນີ້ແມ່ນຫົວຂໍ້ສໍາລັບພາກສ່ວນທີສອງແລ້ວ.

ແຕ່ພຽງພໍ. ຂໍໃຫ້ກ້າວໄປສູ່ໂປໂຕຄອນຢູ່ເທິງສຸດຂອງ serialization ທັງຫມົດນີ້.

MT Proto

ດັ່ງນັ້ນ, ໃຫ້ເປີດ ລາຍ​ລະ​ອຽດ​ທົ່ວ​ໄປ и ລາຍລະອຽດຂອງພິທີການ ແລະສິ່ງທໍາອິດທີ່ພວກເຮົາ stumble over ແມ່ນຄໍາສັບ. ແລະມີຄວາມອຸດົມສົມບູນຂອງທຸກສິ່ງທຸກຢ່າງ. ໂດຍທົ່ວໄປແລ້ວ, ນີ້ເບິ່ງຄືວ່າເປັນຄຸນສົມບັດທີ່ເປັນເຈົ້າຂອງຂອງ Telegram - ການເອີ້ນສິ່ງທີ່ແຕກຕ່າງກັນຢູ່ໃນສະຖານທີ່ຕ່າງໆ, ຫຼືສິ່ງທີ່ແຕກຕ່າງກັນດ້ວຍຄໍາດຽວ, ຫຼືໃນທາງກັບກັນ (ຕົວຢ່າງ, ໃນ API ລະດັບສູງ, ຖ້າທ່ານເຫັນຊຸດສະຕິກເກີ, ມັນບໍ່ແມ່ນ. ເຈົ້າຄິດແນວໃດ).

ຕົວຢ່າງ, "ຂໍ້ຄວາມ" ແລະ "ກອງປະຊຸມ" ຫມາຍຄວາມວ່າບາງສິ່ງບາງຢ່າງທີ່ແຕກຕ່າງກັນຢູ່ທີ່ນີ້ກ່ວາໃນການໂຕ້ຕອບລູກຄ້າ Telegram ປົກກະຕິ. ດີ, ທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງກັບຂໍ້ຄວາມ, ມັນສາມາດຖືກຕີຄວາມຫມາຍໃນຄໍາສັບ OOP, ຫຼືເອີ້ນວ່າ "packet" - ນີ້ແມ່ນຕ່ໍາ, ລະດັບການຂົນສົ່ງ, ບໍ່ມີຂໍ້ຄວາມດຽວກັນກັບໃນການໂຕ້ຕອບ, ມີຫຼາຍຂໍ້ຄວາມບໍລິການ. . ແຕ່ກອງປະຊຸມ ... ແຕ່ສິ່ງທໍາອິດທໍາອິດ.

ຊັ້ນການຂົນສົ່ງ

ສິ່ງທໍາອິດແມ່ນການຂົນສົ່ງ. ພວກເຂົາເຈົ້າຈະບອກພວກເຮົາກ່ຽວກັບ 5 ທາງເລືອກ:

• TCP
• ເຕົ້າຮັບເວັບໄຊຕ໌
• Websocket ຜ່ານ HTTPS
• HTTP
• ສະຖານທີ່ HTTP

Vasily, [15.06.18 15:04] ຍັງມີການຂົນສົ່ງ UDP, ແຕ່ມັນບໍ່ມີເອກະສານ

ແລະ TCP ໃນສາມ variants

ອັນທໍາອິດແມ່ນຄ້າຍຄືກັນກັບ UDP ຫຼາຍກວ່າ TCP, ແຕ່ລະຊຸດປະກອບມີຈໍານວນລໍາດັບແລະ crc
ເປັນຫຍັງການອ່ານເອກະສານຢູ່ໃນລົດເຂັນຈຶ່ງເຈັບປວດ?

ແລ້ວ, ດຽວນີ້ມັນຢູ່ແລ້ວ TCP ມີຢູ່ໃນ 4 ຮຸ່ນແລ້ວ:

• ປະສົມ
• ລະດັບປານກາງ
• padded ກາງ
• ຢ່າງ​ເຕັມ​ທີ່

ດີ, ok, Padded intermediate ສໍາລັບ MTProxy, ນີ້ໄດ້ຖືກເພີ່ມຕໍ່ມາເນື່ອງຈາກເຫດການທີ່ມີຊື່ສຽງ. ແຕ່ເປັນຫຍັງສອງສະບັບ (ສາມໃນຈໍານວນທັງຫມົດ) ເມື່ອເຈົ້າສາມາດໄດ້ຮັບດ້ວຍຫນຶ່ງ? ທັງສີ່ຢ່າງມີຄວາມແຕກຕ່າງກັນພຽງແຕ່ວິທີການກໍານົດຄວາມຍາວແລະ payload ຂອງ MTProto ຕົ້ນຕໍ, ເຊິ່ງຈະໄດ້ຮັບການປຶກສາຫາລືຕື່ມອີກ:

• ໃນຫຍໍ້ມັນແມ່ນ 1 ຫຼື 4 bytes, ແຕ່ບໍ່ແມ່ນ 0xef, ຫຼັງຈາກນັ້ນຮ່າງກາຍ
• ໃນລະດັບປານກາງນີ້ແມ່ນ 4 bytes ຂອງຄວາມຍາວແລະພາກສະຫນາມ, ແລະຄັ້ງທໍາອິດທີ່ລູກຄ້າຕ້ອງສົ່ງ 0xeeeeeeee ເພື່ອຊີ້ບອກວ່າມັນເປັນລະດັບປານກາງ
• ໃນເຕັມທີ່ຕິດຫຼາຍທີ່ສຸດ, ຈາກທັດສະນະຂອງເຄືອຂ່າຍ: ຄວາມຍາວ, ຈໍານວນລໍາດັບ, ແລະບໍ່ແມ່ນອັນທີ່ສ່ວນໃຫຍ່ແມ່ນ MTProto, ຮ່າງກາຍ, CRC32. ແມ່ນແລ້ວ, ທັງໝົດນີ້ແມ່ນຢູ່ເທິງສຸດຂອງ TCP. ເຊິ່ງໃຫ້ພວກເຮົາມີການຂົນສົ່ງທີ່ເຊື່ອຖືໄດ້ໃນຮູບແບບຂອງກະແສໄບຕ໌ຕາມລໍາດັບ; ບໍ່ຈໍາເປັນລໍາດັບ, ໂດຍສະເພາະ checksums. ຕົກລົງ, ຕອນນີ້ບາງຄົນຈະຄັດຄ້ານຂ້ອຍວ່າ TCP ມີ 16-bit checksum, ດັ່ງນັ້ນຂໍ້ມູນເສຍຫາຍເກີດຂື້ນ. ຍິ່ງໃຫຍ່, ແຕ່ຕົວຈິງແລ້ວພວກເຮົາມີໂປໂຕຄອນ cryptographic ທີ່ມີ hashes ຍາວກວ່າ 16 bytes, ຄວາມຜິດພາດທັງຫມົດເຫຼົ່ານີ້ - ແລະຫຼາຍກວ່ານັ້ນ - ຈະຖືກຈັບໄດ້ໂດຍ SHA mismatch ໃນລະດັບທີ່ສູງກວ່າ. ບໍ່ມີຈຸດໃດຢູ່ໃນ CRC32 ຢູ່ເທິງສຸດນີ້.

ໃຫ້ສົມທຽບແບບຫຍໍ້, ໃນຫນຶ່ງ byte ຂອງຄວາມຍາວແມ່ນເປັນໄປໄດ້, ກັບ Intermediate, ເຊິ່ງ justifies "ໃນກໍລະນີທີ່ຕ້ອງການການຈັດລຽງຂໍ້ມູນ 4-byte," ຊຶ່ງເປັນເລື່ອງໄຮ້ສາລະ. ແມ່ນຫຍັງ, ມັນເຊື່ອກັນວ່ານັກຂຽນໂປລແກລມ Telegram ບໍ່ມີຄວາມສາມາດທີ່ບໍ່ສາມາດອ່ານຂໍ້ມູນຈາກຊັອກເກັດເຂົ້າໄປໃນ buffer ທີ່ສອດຄ່ອງ? ທ່ານຍັງຕ້ອງເຮັດແນວນີ້, ເພາະວ່າການອ່ານສາມາດສົ່ງຄືນທ່ານຈໍານວນ bytes ໃດ (ແລະຍັງມີເຄື່ອງແມ່ຂ່າຍຕົວແທນ, ຕົວຢ່າງ ...). ຫຼືໃນທາງກົງກັນຂ້າມ, ເປັນຫຍັງບລັອກ Abridged ຖ້າພວກເຮົາຈະມີ padding hefty ຢູ່ເທິງສຸດຂອງ 16 bytes - ປະຫຍັດ 3 bytes ບາງຄັ້ງ ?

ຄົນຫນຶ່ງໄດ້ຮັບຄວາມປະທັບໃຈທີ່ Nikolai Durov ກໍ່ມັກທີ່ຈະປະດິດລໍ້, ລວມທັງໂປໂຕຄອນເຄືອຂ່າຍ, ໂດຍບໍ່ມີຄວາມຕ້ອງການຕົວຈິງ.

ທາງເລືອກການຂົນສົ່ງອື່ນໆ, ລວມທັງ. ເວັບແລະ MTProxy, ພວກເຮົາຈະບໍ່ພິຈາລະນາໃນປັດຈຸບັນ, ອາດຈະຢູ່ໃນການຕອບອື່ນ, ຖ້າມີການຮ້ອງຂໍ. ກ່ຽວກັບ MTProxy ດຽວກັນນີ້, ໃຫ້ພວກເຮົາຈື່ພຽງແຕ່ວ່າບໍ່ດົນຫລັງຈາກການເປີດຕົວໃນປີ 2018, ຜູ້ໃຫ້ບໍລິການໄດ້ຮຽນຮູ້ທີ່ຈະບລັອກມັນຢ່າງໄວວາ, ມີຈຸດປະສົງເພື່ອ bypass ສະກັດໂດຍ ຂະໜາດຊຸດ! ແລະຄວາມຈິງທີ່ວ່າເຊີບເວີ MTProxy ທີ່ຂຽນ (ອີກເທື່ອຫນຶ່ງໂດຍ Waltman) ໃນ C ໄດ້ຖືກຜູກມັດຫຼາຍເກີນໄປກັບສະເພາະຂອງ Linux, ເຖິງແມ່ນວ່ານີ້ບໍ່ຈໍາເປັນຕ້ອງມີທັງຫມົດ (Phil Kulin ຈະຢືນຢັນ), ແລະວ່າເຄື່ອງແມ່ຂ່າຍທີ່ຄ້າຍຄືກັນຢູ່ໃນ Go ຫຼື Node.js ຈະ. ພໍດີຢູ່ໃນບໍ່ເກີນຮ້ອຍສາຍ.

ແຕ່ພວກເຮົາຈະສະຫຼຸບກ່ຽວກັບຄວາມຮູ້ດ້ານວິຊາການຂອງປະຊາຊົນເຫຼົ່ານີ້ໃນຕອນທ້າຍຂອງພາກ, ຫຼັງຈາກພິຈາລະນາບັນຫາອື່ນໆ. ສໍາລັບໃນປັດຈຸບັນ, ໃຫ້ຍ້າຍໄປ OSI layer 5, session - ທີ່ເຂົາເຈົ້າວາງ session MTProto.

ກະແຈ, ຂໍ້ຄວາມ, ກອງປະຊຸມ, Diffie-Hellman

ເຂົາເຈົ້າວາງໄວ້ບ່ອນນັ້ນບໍ່ຖືກຕ້ອງທັງໝົດ... ເຊດຊັນບໍ່ແມ່ນເຊດຊັນດຽວກັບທີ່ເຫັນໄດ້ໃນສ່ວນຕິດຕໍ່ພາຍໃຕ້ Active sessions. ແຕ່ໃນຄໍາສັ່ງ.

ດັ່ງນັ້ນພວກເຮົາໄດ້ຮັບສາຍພັນໄບຕ໌ຂອງຄວາມຍາວທີ່ຮູ້ຈັກຈາກຊັ້ນການຂົນສົ່ງ. ນີ້ແມ່ນຂໍ້ຄວາມທີ່ຖືກເຂົ້າລະຫັດຫຼືຂໍ້ຄວາມທໍາມະດາ - ຖ້າພວກເຮົາຍັງຢູ່ໃນຂັ້ນຕອນການຕົກລົງທີ່ສໍາຄັນແລະກໍາລັງປະຕິບັດຕົວຈິງ. ແນວຄວາມຄິດອັນໃດທີ່ເອີ້ນວ່າ "ກຸນແຈ" ທີ່ພວກເຮົາເວົ້າກ່ຽວກັບ? ຂໍຄວາມກະຈ່າງແຈ້ງກ່ຽວກັບບັນຫານີ້ສໍາລັບທີມງານ Telegram ເອງ (ຂ້ອຍຂໍໂທດສໍາລັບການແປເອກະສານຂອງຂ້ອຍເອງຈາກພາສາອັງກິດດ້ວຍສະຫມອງທີ່ເມື່ອຍລ້າໃນເວລາ 4 ໂມງເຊົ້າ, ມັນງ່າຍກວ່າທີ່ຈະປະໄວ້ບາງປະໂຫຍກ):

ມີສອງຫນ່ວຍງານທີ່ເອີ້ນວ່າ ກອງປະຊຸມ - ຫນຶ່ງໃນ UI ຂອງລູກຄ້າຢ່າງເປັນທາງການພາຍໃຕ້ "ກອງປະຊຸມໃນປະຈຸບັນ", ເຊິ່ງແຕ່ລະກອງປະຊຸມກົງກັບອຸປະກອນທັງຫມົດ / OS.
ສອງ - ຊ່ວງເວລາ MTProto, ທີ່ມີຈໍານວນລໍາດັບຂອງຂໍ້ຄວາມ (ໃນຄວາມຮູ້ສຶກໃນລະດັບຕ່ໍາ) ໃນມັນ, ແລະອັນໃດ ອາດຈະຢູ່ລະຫວ່າງການເຊື່ອມຕໍ່ TCP ທີ່ແຕກຕ່າງກັນ. ສາມາດຕິດຕັ້ງ MTProto ຫຼາຍຄັ້ງໃນເວລາດຽວກັນ, ຕົວຢ່າງ, ເພື່ອເລັ່ງການດາວໂຫຼດໄຟລ໌.

ລະຫວ່າງສອງອັນນີ້ ກອງປະຊຸມ ມີແນວຄວາມຄິດ ການອະນຸຍາດ. ໃນກໍລະນີ degenerate, ພວກເຮົາສາມາດເວົ້າໄດ້ ຊ່ວງເວລາ UI ແມ່ນຄືກັນກັບ ການອະນຸຍາດ, ແຕ່ອະນິຈາ, ທຸກສິ່ງທຸກຢ່າງແມ່ນສັບສົນ. ໃຫ້ເບິ່ງ:

• ຜູ້ໃຊ້ໃນອຸປະກອນໃຫມ່ທໍາອິດສ້າງ auth_key ແລະຜູກມັນໄວ້ໃນບັນຊີ, ຕົວຢ່າງຜ່ານ SMS - ນັ້ນແມ່ນເຫດຜົນ ການອະນຸຍາດ
• ມັນເກີດຂຶ້ນພາຍໃນຄັ້ງທໍາອິດ ຊ່ວງເວລາ MTProto, ເຊິ່ງມີ session_id ພາຍ​ໃນ​ຕົວ​ທ່ານ​ເອງ​.
• ໃນຂັ້ນຕອນນີ້, ການປະສົມປະສານ ການອະນຸຍາດ и session_id ສາມາດເອີ້ນໄດ້ ຕົວຢ່າງ - ຄໍານີ້ປາກົດຢູ່ໃນເອກະສານແລະລະຫັດຂອງລູກຄ້າຈໍານວນຫນຶ່ງ
• ຫຼັງຈາກນັ້ນ, ລູກຄ້າສາມາດເປີດໄດ້ ຫຼາຍໆຄັ້ງ ຊ່ວງເວລາ MTProto ພາຍໃຕ້ການດຽວກັນ auth_key - ກັບ DC ດຽວກັນ.
• ຫຼັງຈາກນັ້ນ, ມື້ຫນຶ່ງລູກຄ້າຈະຕ້ອງຮ້ອງຂໍໄຟລ໌ຈາກ DC ອື່ນ - ແລະສໍາລັບການນີ້ DC ໃຫມ່ຈະໄດ້ຮັບການຜະລິດ auth_key !
• ເພື່ອແຈ້ງໃຫ້ລະບົບວ່າມັນບໍ່ແມ່ນຜູ້ໃຊ້ໃຫມ່ທີ່ລົງທະບຽນ, ແຕ່ຄືກັນ ການອະນຸຍາດ (ຊ່ວງເວລາ UI), ລູກຄ້າໃຊ້ການໂທ API auth.exportAuthorization ໃນ​ບ້ານ DC auth.importAuthorization ໃນ DC ໃຫມ່.
• ທຸກສິ່ງທຸກຢ່າງແມ່ນຄືກັນ, ຫຼາຍໆຄົນອາດຈະເປີດ ຊ່ວງເວລາ MTProto (ແຕ່ລະຄົນມີຂອງຕົນເອງ session_id) ກັບ DC ໃຫມ່ນີ້, ພາຍໃຕ້ ລາວ auth_key.
• ສຸດທ້າຍ, ລູກຄ້າອາດຈະຕ້ອງການ Perfect Forward Secrecy. ທຸກໆ auth_key ແມ່ນ ຖາວອນ key - per DC - ແລະລູກຄ້າສາມາດໂທຫາ auth.bindTempAuthKey ສໍາລັບການນໍາໃຊ້ ຊົ່ວຄາວ auth_key - ແລະອີກເທື່ອຫນຶ່ງ, ພຽງແຕ່ຫນຶ່ງ temp_auth_key ຕໍ່ DC, ທົ່ວໄປກັບທຸກຄົນ ຊ່ວງເວລາ MTProto ກັບ DC ນີ້.

ແຈ້ງການ, ນັ້ນ ເກືອ (ແລະເກືອໃນອະນາຄົດ) ຍັງເປັນອັນຫນຶ່ງ auth_key ເຫຼົ່ານັ້ນ. ແບ່ງປັນລະຫວ່າງທຸກຄົນ ຊ່ວງເວລາ MTProto ກັບ DC ດຽວກັນ.

"ລະຫວ່າງການເຊື່ອມຕໍ່ TCP ທີ່ແຕກຕ່າງກັນ" ຫມາຍຄວາມວ່າແນວໃດ? ດັ່ງນັ້ນນີ້ຫມາຍຄວາມວ່າ ບາງສິ່ງບາງຢ່າງເຊັ່ນ: ຄຸກກີການອະນຸຍາດຢູ່ໃນເວັບໄຊທ໌ - ມັນຍັງຄົງຢູ່ (ຢູ່ລອດ) ການເຊື່ອມຕໍ່ TCP ຫຼາຍກັບເຄື່ອງແມ່ຂ່າຍທີ່ໃຫ້, ແຕ່ມື້ຫນຶ່ງມັນບໍ່ດີ. ບໍ່ເຫມືອນກັບ HTTP, ໃນຂໍ້ຄວາມ MTProto ພາຍໃນເຊດຊັນແມ່ນເປັນລໍາດັບແລະຢືນຢັນ; ຖ້າພວກເຂົາເຂົ້າໄປໃນອຸໂມງ, ການເຊື່ອມຕໍ່ຖືກທໍາລາຍ - ຫຼັງຈາກສ້າງການເຊື່ອມຕໍ່ໃຫມ່, ເຄື່ອງແມ່ຂ່າຍຈະສົ່ງທຸກສິ່ງທຸກຢ່າງໃນກອງປະຊຸມນີ້ທີ່ມັນບໍ່ໄດ້ສົ່ງໃນກ່ອນຫນ້ານີ້. ການເຊື່ອມຕໍ່ TCP.

ຢ່າງໃດກໍ່ຕາມ, ຂໍ້ມູນຂ້າງເທິງນີ້ແມ່ນສະຫຼຸບໄດ້ຫຼັງຈາກການສືບສວນຫຼາຍເດືອນ. ໃນເວລານີ້, ພວກເຮົາປະຕິບັດລູກຄ້າຂອງພວກເຮົາຕັ້ງແຕ່ເລີ່ມຕົ້ນບໍ? - ໃຫ້ເຮົາກັບຄືນສູ່ຈຸດເລີ່ມຕົ້ນ.

ສະນັ້ນໃຫ້ພວກເຮົາສ້າງ auth_key on the ຮຸ່ນ Diffie-Hellman ຈາກ Telegram. ລອງເຂົ້າໃຈເອກະສານ...

Vasily, [19.06.18 20:05] data_with_hash := SHA1(data) + data + ( any random bytes ); ເຊັ່ນວ່າຄວາມຍາວເທົ່າກັບ 255 bytes;
encrypted_data := RSA(data_with_hash, server_public_key); ຕົວເລກຍາວ 255 ໄບຕ໌ (ໃຫຍ່ endian) ຖືກຍົກຂຶ້ນມາເປັນພະລັງງານທີ່ຈຳເປັນຫຼາຍກວ່າໂມດູລທີ່ຈຳເປັນ, ແລະ ຜົນໄດ້ຮັບຈະຖືກເກັບໄວ້ເປັນຕົວເລກ 256 ໄບຕ໌.

ພວກເຂົາເຈົ້າມີ dope DH ບາງ

ບໍ່ຄືກັບ DH ຂອງຄົນທີ່ມີສຸຂະພາບດີ
ບໍ່ມີກະແຈສາທາລະນະສອງອັນໃນ dx

ດີ, ໃນທີ່ສຸດນີ້ໄດ້ຖືກຄັດອອກ, ແຕ່ສິ່ງເສດເຫຼືອທີ່ຍັງຄົງຢູ່ - ຫຼັກຖານຂອງການເຮັດວຽກແມ່ນເຮັດໂດຍລູກຄ້າວ່າລາວສາມາດເອົາຕົວເລກໄດ້. ປະເພດຂອງການປ້ອງກັນການໂຈມຕີ DoS. ແລະກະແຈ RSA ຖືກນໍາໃຊ້ພຽງແຕ່ຄັ້ງດຽວໃນທິດທາງດຽວ, ສໍາຄັນສໍາລັບການເຂົ້າລະຫັດ new_nonce. ແຕ່ໃນຂະນະທີ່ການປະຕິບັດງານທີ່ເບິ່ງຄືວ່າງ່າຍດາຍນີ້ຈະປະສົບຜົນສໍາເລັດ, ເຈົ້າຈະຕ້ອງປະເຊີນກັບຫຍັງ?

Vasily, [20.06.18/00/26 XNUMX:XNUMX] ຂ້ອຍຍັງບໍ່ທັນໄດ້ຮັບຄໍາຮ້ອງຂໍ appid ເທື່ອ

ຂ້າພະເຈົ້າໄດ້ສົ່ງຄໍາຮ້ອງຂໍນີ້ໄປຫາ DH

ແລະ, ໃນ dock ການຂົນສົ່ງມັນບອກວ່າມັນສາມາດຕອບສະຫນອງກັບ 4 bytes ຂອງລະຫັດຄວາມຜິດພາດ. ຫມົດ​ເທົ່າ​ນີ້

ແລ້ວ, ລາວບອກຂ້ອຍ -404, ດັ່ງນັ້ນແມ່ນຫຍັງ?

ສະນັ້ນຂ້ອຍບອກລາວວ່າ: "ຈັບ bullshit ຂອງທ່ານເຂົ້າລະຫັດດ້ວຍລະຫັດເຊີຟເວີດ້ວຍລາຍນິ້ວມືແບບນີ້, ຂ້ອຍຕ້ອງການ DH," ແລະມັນຕອບດ້ວຍ 404 ໂງ່.

ເຈົ້າຄິດແນວໃດກັບການຕອບສະໜອງຂອງເຊີບເວີນີ້? ຈະເຮັດແນວໃດ? ບໍ່ມີໃຜຖາມ (ແຕ່ມີຫຼາຍກວ່ານັ້ນໃນພາກທີສອງ).

ທີ່ນີ້ຄວາມສົນໃຈທັງຫມົດແມ່ນເຮັດຢູ່ໃນ dock ໄດ້

ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ມີ​ຫຍັງ​ອີກ​ແດ່​ທີ່​ຈະ​ເຮັດ​, ຂ້າ​ພະ​ເຈົ້າ​ພຽງ​ແຕ່​ຝັນ​ຢາກ​ຈະ​ປ່ຽນ​ຕົວ​ເລກ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​

ສອງຕົວເລກ 32 ບິດ. ຂ້າພະເຈົ້າໄດ້ຫຸ້ມຫໍ່ພວກມັນຄືກັບຄົນອື່ນ

ແຕ່ບໍ່, ສອງອັນນີ້ຈໍາເປັນຕ້ອງໄດ້ເພີ່ມເຂົ້າໃນແຖວທໍາອິດເປັນ BE

Vadim Goncharov, [20.06.18 15:49] ແລະເນື່ອງຈາກວ່ານີ້ 404?

Vasily, [20.06.18 15:49] ແມ່ນແລ້ວ!

Vadim Goncharov, [20.06.18 15:50] ສະນັ້ນຂ້ອຍບໍ່ເຂົ້າໃຈສິ່ງທີ່ລາວສາມາດ "ບໍ່ພົບ"

Vasily, [20.06.18 15:50] ປະມານ

ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ຊອກ​ຫາ​ການ​ເສື່ອມ​ສະ​ພາບ​ດັ່ງ​ກ່າວ​ເປັນ​ປັດ​ໄຈ​ທີ່​ສໍາ​ຄັນ​)​.

ພວກເຮົາບໍ່ໄດ້ຈັດການການລາຍງານຂໍ້ຜິດພາດ

Vasily, [20.06.18 20:18] ໂອ້, ຍັງມີ MD5. ແລ້ວສາມ hashes ທີ່ແຕກຕ່າງກັນ

ລາຍນິ້ວມືຫຼັກແມ່ນຄຳນວນດັ່ງນີ້:

digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

SHA1 ແລະ sha2

ສະນັ້ນໃຫ້ເຮົາໃສ່ມັນ auth_key ພວກເຮົາໄດ້ຮັບ 2048 bits ໃນຂະຫນາດໂດຍໃຊ້ Diffie-Hellman. ຕໍ່ໄປແມ່ນຫຍັງ? ຕໍ່ໄປພວກເຮົາຄົ້ນພົບວ່າ 1024 bits ຕ່ໍາຂອງລະຫັດນີ້ບໍ່ໄດ້ຖືກນໍາໃຊ້ໃນທາງໃດກໍ່ຕາມ ... ແຕ່ຂໍໃຫ້ຄິດກ່ຽວກັບເລື່ອງນີ້ສໍາລັບຕອນນີ້. ໃນຂັ້ນຕອນນີ້, ພວກເຮົາມີຄວາມລັບທີ່ແບ່ງປັນກັບເຄື່ອງແມ່ຂ່າຍ. ການປຽບທຽບຂອງກອງປະຊຸມ TLS ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ, ເຊິ່ງເປັນຂັ້ນຕອນທີ່ມີລາຄາແພງຫຼາຍ. ແຕ່ເຊີບເວີຍັງບໍ່ຮູ້ຫຍັງເລີຍວ່າພວກເຮົາແມ່ນໃຜ! ຍັງບໍ່ທັນ, ຕົວຈິງແລ້ວ. ການອະນຸຍາດ. ເຫຼົ່ານັ້ນ. ຖ້າທ່ານຄິດໃນແງ່ຂອງ "ເຂົ້າສູ່ລະບົບລະຫັດຜ່ານ", ດັ່ງທີ່ທ່ານເຄີຍເຮັດໃນ ICQ, ຫຼືຢ່າງຫນ້ອຍ "login-key", ໃນ SSH (ຕົວຢ່າງ, ໃນບາງ gitlab / github). ພວກເຮົາໄດ້ຮັບອັນໜຶ່ງທີ່ບໍ່ເປີດເຜີຍຊື່. ຈະເປັນແນວໃດຖ້າເຄື່ອງແມ່ຂ່າຍບອກພວກເຮົາວ່າ "ເບີໂທລະສັບເຫຼົ່ານີ້ຖືກໃຫ້ບໍລິການໂດຍ DC ອື່ນ"? ຫຼືແມ້ກະທັ້ງ "ເບີໂທລະສັບຂອງເຈົ້າຖືກຫ້າມ"? ທີ່ດີທີ່ສຸດທີ່ພວກເຮົາສາມາດເຮັດໄດ້ແມ່ນຮັກສາກຸນແຈໃນຄວາມຫວັງວ່າມັນເປັນປະໂຫຍດແລະຈະບໍ່ເນົ່າເປື່ອຍໃນເວລານັ້ນ.

ໂດຍວິທີທາງການ, ພວກເຮົາ "ໄດ້ຮັບ" ມັນດ້ວຍການຈອງ. ຕົວຢ່າງ, ພວກເຮົາໄວ້ວາງໃຈເຄື່ອງແມ່ຂ່າຍບໍ? ຈະເປັນແນວໃດຖ້າມັນປອມ? ການກວດສອບການເຂົ້າລະຫັດລັບແມ່ນຈໍາເປັນ:

Vasily, [21.06.18 17:53] ພວກເຂົາສະເຫນີໃຫ້ລູກຄ້າມືຖືກວດເບິ່ງຈໍານວນ 2kbit ສໍາລັບ primality%)

ແຕ່ມັນບໍ່ຊັດເຈນເລີຍ, nafeijoa

Vasily, [21.06.18 18:02] ເອກະສານບໍ່ໄດ້ບອກວ່າຈະເຮັດແນວໃດຖ້າມັນກາຍເປັນບໍ່ງ່າຍດາຍ

ບໍ່ໄດ້ເວົ້າ. ໃຫ້ເບິ່ງສິ່ງທີ່ລູກຄ້າ Android ຢ່າງເປັນທາງການເຮັດໃນກໍລະນີນີ້? ກ ນັ້ນແມ່ນສິ່ງທີ່ (ແລະແມ່ນແລ້ວ, ໄຟລ໌ທັງຫມົດແມ່ນຫນ້າສົນໃຈ) - ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, ຂ້ອຍຈະອອກຈາກນີ້ຢູ່ທີ່ນີ້:

278     static const char *goodPrime = "c71caeb9c6b1c9048e6c522f70f13f73980d40238e3e21c14934d037563d930f48198a0aa7c14058229493d22530f4dbfa336f6e0ac925139543aed44cce7c3720fd51f69458705ac68cd4fe6b6b13abdc9746512969328454f18faf8c595f642477fe96bb2a941d5bcd1d4ac8cc49880708fa9b378e3c4f3a9060bee67cf9a4a4a695811051907e162753b56b0f6b410dba74d8a84b2a14b3144e0ef1284754fd17ed950d5965b4b9dd46582db1178d169c6bc465b0d6ff9ca3928fef5b9ae4e418fc15e83ebea0f87fa9ff5eed70050ded2849f47bf959d956850ce929851f0d8115f635b105ee2e4e15d04b2454bf6f4fadf034b10403119cd8e3b92fcc5b";
279   if (!strcasecmp(prime, goodPrime)) {

ບໍ່, ແນ່ນອນມັນຍັງມີຢູ່ ບາງ ມີ​ການ​ທົດ​ສອບ​ສໍາ​ລັບ​ການ​ທໍາ​ອິດ​ຂອງ​ຈໍາ​ນວນ​, ແຕ່​ສ່ວນ​ບຸກ​ຄົນ​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ມີ​ຄວາມ​ຮູ້​ຄະ​ນິດ​ສາດ​ພຽງ​ພໍ​ຕໍ່​ໄປ​ອີກ​ແລ້ວ​.

ຕົກລົງ, ພວກເຮົາໄດ້ຮັບລະຫັດຫຼັກ. ເພື່ອເຂົ້າສູ່ລະບົບ, i.e. ສົ່ງຄໍາຮ້ອງຂໍ, ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດການເຂົ້າລະຫັດເພີ່ມເຕີມ, ການນໍາໃຊ້ AES.

ລະຫັດຂໍ້ຄວາມແມ່ນຖືກກໍານົດເປັນ 128 bits ກາງຂອງ SHA256 ຂອງຮ່າງກາຍຂໍ້ຄວາມ (ລວມທັງ session, message ID, ແລະອື່ນໆ), ລວມທັງ padding bytes, prepended ໂດຍ 32 bytes ທີ່ເອົາມາຈາກກະແຈການອະນຸຍາດ.

Vasily, [22.06.18 14:08] ໂດຍສະເລ່ຍ, bitch, bits

ໄດ້ auth_key. ທັງໝົດ. ນອກ ເໜືອ ໄປຈາກພວກມັນ ... ມັນບໍ່ຈະແຈ້ງຈາກເອກະສານ. ຮູ້ສຶກວ່າບໍ່ເສຍຄ່າເພື່ອສຶກສາລະຫັດແຫຼ່ງເປີດ.

ໃຫ້ສັງເກດວ່າ MTProto 2.0 ຕ້ອງການຈາກ 12 ຫາ 1024 bytes ຂອງ padding, ຍັງຂຶ້ນກັບເງື່ອນໄຂວ່າຄວາມຍາວຂອງຂໍ້ຄວາມຖືກແບ່ງອອກດ້ວຍ 16 bytes.

ດັ່ງນັ້ນທ່ານຄວນເພີ່ມ padding ຫຼາຍປານໃດ?

ແລະແມ່ນແລ້ວ, ຍັງມີ 404 ໃນກໍລະນີທີ່ມີຂໍ້ຜິດພາດ

ຖ້າຜູ້ໃດໄດ້ສຶກສາແຜນວາດແລະຂໍ້ຄວາມຂອງເອກະສານຢ່າງລະມັດລະວັງ, ພວກເຂົາສັງເກດເຫັນວ່າບໍ່ມີ MAC ຢູ່ທີ່ນັ້ນ. ແລະວ່າ AES ຖືກໃຊ້ໃນໂຫມດ IGE ທີ່ແນ່ນອນທີ່ບໍ່ໄດ້ໃຊ້ບ່ອນອື່ນ. ພວກເຂົາ, ແນ່ນອນ, ຂຽນກ່ຽວກັບເລື່ອງນີ້ໃນ FAQ ຂອງພວກເຂົາ ... ທີ່ນີ້, ເຊັ່ນ, ລະຫັດຂໍ້ຄວາມຕົວມັນເອງຍັງເປັນ SHA hash ຂອງຂໍ້ມູນທີ່ຖອດລະຫັດ, ໃຊ້ເພື່ອກວດສອບຄວາມສົມບູນ - ແລະໃນກໍລະນີທີ່ບໍ່ກົງກັນ, ເອກະສານສໍາລັບເຫດຜົນບາງຢ່າງ. ແນະນໍາໃຫ້ບໍ່ສົນໃຈພວກເຂົາຢ່າງງຽບໆ (ແຕ່ກ່ຽວກັບຄວາມປອດໄພ, ຈະເປັນແນວໃດຖ້າພວກເຂົາທໍາລາຍພວກເຮົາ?).

ຂ້ອຍບໍ່ແມ່ນນັກຂຽນລະຫັດລັບ, ບາງທີອາດບໍ່ມີຫຍັງຜິດພາດກັບຮູບແບບນີ້ໃນກໍລະນີນີ້ຈາກທັດສະນະທາງທິດສະດີ. ແຕ່ຂ້ອຍສາມາດຕັ້ງຊື່ບັນຫາພາກປະຕິບັດໄດ້ຢ່າງຊັດເຈນ, ການນໍາໃຊ້ Telegram Desktop ເປັນຕົວຢ່າງ. ມັນເຂົ້າລະຫັດຖານຄວາມຈໍາທ້ອງຖິ່ນ (ທັງຫມົດເຫຼົ່ານີ້ D877F783D5D3EF8C) ໃນລັກສະນະດຽວກັນກັບຂໍ້ຄວາມໃນ MTProto (ພຽງແຕ່ໃນກໍລະນີນີ້ສະບັບ 1.0), i.e. ທໍາອິດທີ່ລະຫັດຂໍ້ຄວາມ, ຫຼັງຈາກນັ້ນຂໍ້ມູນຕົວມັນເອງ (ແລະບາງບ່ອນຫລີກໄປທາງຫນຶ່ງໃຫຍ່ auth_key 256 bytes, ໂດຍບໍ່ມີການທີ່ msg_key ໄຮ້ປະໂຫຍດ). ດັ່ງນັ້ນ, ບັນຫາຈະກາຍເປັນສັງເກດເຫັນໃນໄຟລ໌ຂະຫນາດໃຫຍ່. ຄື, ທ່ານຈໍາເປັນຕ້ອງຮັກສາສອງສໍາເນົາຂອງຂໍ້ມູນ - ເຂົ້າລະຫັດແລະຖອດລະຫັດ. ແລະຖ້າຫາກວ່າມີ megabytes, ຫຼື streaming ວິດີໂອ, ສໍາລັບການຍົກຕົວຢ່າງ?.. ຮູບແບບຄລາສສິກກັບ MAC ຫຼັງຈາກ ciphertext ອະນຸຍາດໃຫ້ທ່ານສາມາດອ່ານມັນນ້ໍາ, ທັນທີທັນໃດສົ່ງ. ແຕ່ກັບ MTProto ທ່ານຈະຕ້ອງ ໃນຄັ້ງທໍາອິດ ເຂົ້າລະຫັດຫຼືຖອດລະຫັດຂໍ້ຄວາມທັງຫມົດ, ພຽງແຕ່ຫຼັງຈາກນັ້ນໂອນມັນກັບເຄືອຂ່າຍຫຼືແຜ່ນ. ດັ່ງນັ້ນ, ໃນສະບັບຫລ້າສຸດຂອງ Telegram Desktop ໃນ cache in user_data ຮູບແບບອື່ນຍັງຖືກນໍາໃຊ້ - ກັບ AES ໃນຮູບແບບ CTR.

Vasily, [21.06.18 01:27] ໂອ້, ຂ້ອຍໄດ້ຄົ້ນພົບວ່າ IGE ແມ່ນຫຍັງ: IGE ແມ່ນຄວາມພະຍາຍາມທໍາອິດໃນ "ໂຫມດການເຂົ້າລະຫັດລັບ", ໃນເບື້ອງຕົ້ນສໍາລັບ Kerberos. ມັນ​ເປັນ​ຄວາມ​ພະ​ຍາ​ຍາມ​ທີ່​ບໍ່​ສໍາ​ເລັດ (ມັນ​ບໍ່​ໄດ້​ໃຫ້​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ຄວາມ​ຊື່​ສັດ​)​, ແລະ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ເອົາ​ອອກ​. ນັ້ນແມ່ນການເລີ່ມຕົ້ນຂອງການຄົ້ນຫາ 20 ປີສໍາລັບໂຫມດການເຂົ້າລະຫັດລັບທີ່ເຮັດວຽກ, ເຊິ່ງບໍ່ດົນມານີ້ໄດ້ສິ້ນສຸດລົງໃນໂຫມດເຊັ່ນ OCB ແລະ GCM.

ແລະໃນປັດຈຸບັນການໂຕ້ຖຽງຈາກຂ້າງໂຄງຮ່າງການ:

ທີມງານທີ່ຢູ່ເບື້ອງຫລັງຂອງ Telegram, ນໍາໂດຍ Nikolai Durov, ປະກອບດ້ວຍຫົກແຊ້ມ ACM, ເຄິ່ງຫນຶ່ງຂອງພວກເຂົາປະລິນຍາເອກໃນຄະນິດສາດ. ມັນໃຊ້ເວລາປະມານສອງປີເພື່ອເປີດຕົວ MTProto ລຸ້ນປະຈຸບັນ.

ນັ້ນເປັນເລື່ອງຕະຫລົກ. ສອງປີໃນລະດັບຕ່ໍາ

ຫຼືທ່ານພຽງແຕ່ສາມາດໃຊ້ເວລາ tls

ຕົກລົງ, ໃຫ້ເວົ້າວ່າພວກເຮົາໄດ້ເຮັດການເຂົ້າລະຫັດລັບ ແລະຄວາມແຕກຕ່າງອື່ນໆ. ມັນເປັນໄປໄດ້ສຸດທ້າຍທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍ serialized ໃນ TL ແລະ deserialize ຄໍາຕອບ? ດັ່ງນັ້ນເຈົ້າຄວນສົ່ງຫຍັງແລະແນວໃດ? ນີ້, ໃຫ້ເວົ້າວ່າ, ວິທີການ initConnection, ບາງທີນີ້ແມ່ນມັນ?

Vasily, [25.06.18 18:46] ເລີ່ມຕົ້ນການເຊື່ອມຕໍ່ແລະບັນທຶກຂໍ້ມູນໃນອຸປະກອນແລະແອັບພລິເຄຊັນຂອງຜູ້ໃຊ້.

ມັນຍອມຮັບ app_id, device_model, system_version, app_version ແລະ lang_code.

ແລະບາງຄໍາຖາມ

ເອກະສານຕາມເຄີຍ. ຮູ້ສຶກວ່າບໍ່ເສຍຄ່າເພື່ອສຶກສາແຫຼ່ງເປີດ

ຖ້າທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງໂດຍປະມານກັບ invokeWithLayer, ແລ້ວມີຫຍັງຜິດພາດຢູ່ທີ່ນີ້? ມັນຫັນອອກ, ໃຫ້ເວົ້າວ່າພວກເຮົາມີ - ລູກຄ້າມີບາງສິ່ງບາງຢ່າງທີ່ຈະຖາມເຄື່ອງແມ່ຂ່າຍກ່ຽວກັບ - ມີຄໍາຮ້ອງຂໍທີ່ພວກເຮົາຕ້ອງການສົ່ງ:

Vasily, [25.06.18 19:13] Judging by the code, call first is wrapped in this crap, and the crap itself is wrapped in invokewithlayer

ເປັນຫຍັງບໍ່ສາມາດ initConnection ເປັນການໂທແຍກຕ່າງຫາກ, ແຕ່ຕ້ອງເປັນ wrapper? ແມ່ນແລ້ວ, ຍ້ອນວ່າມັນໄດ້ຫັນອອກ, ມັນຕ້ອງເຮັດທຸກຄັ້ງໃນຕອນເລີ່ມຕົ້ນຂອງແຕ່ລະກອງປະຊຸມ, ແລະບໍ່ແມ່ນຄັ້ງດຽວ, ເຊັ່ນດຽວກັບລະຫັດຕົ້ນຕໍ. ແຕ່! ມັນບໍ່ສາມາດຖືກເອີ້ນໂດຍຜູ້ໃຊ້ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ! ໃນປັດຈຸບັນພວກເຮົາໄດ້ບັນລຸຂັ້ນຕອນທີ່ມັນສາມາດໃຊ້ໄດ້ ອັນນີ້ ຫນ້າເອກະສານ - ແລະມັນບອກພວກເຮົາວ່າ ...

ມີພຽງແຕ່ສ່ວນນ້ອຍຂອງວິທີການ API ເທົ່ານັ້ນທີ່ມີໃຫ້ກັບຜູ້ໃຊ້ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ:

• auth.sendCode
• auth.resendCode
• account.getPassword
• auth.checkPassword
• auth.checkPhone
• auth.signUp
• auth.ເຂົ້າສູ່ລະບົບ
• auth.import ການອະນຸຍາດ
• help.getConfig
• help.getNearestDc
• help.getAppUpdate
• help.getCdnConfig
• langpack.getLangPack
• langpack.getStrings
• langpack.getDifference
• langpack.getLanguages
• langpack.getLanguage

ທໍາອິດຂອງພວກເຂົາ, auth.sendCode, ແລະມີຄໍາຮ້ອງຂໍທໍາອິດທີ່ຮັກແພງທີ່ພວກເຮົາສົ່ງ api_id ແລະ api_hash, ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ຮັບ SMS ທີ່ມີລະຫັດ. ແລະຖ້າພວກເຮົາຢູ່ໃນ DC ຜິດ (ຫມາຍເລກໂທລະສັບໃນປະເທດນີ້ແມ່ນໃຫ້ບໍລິການໂດຍຄົນອື່ນ, ສໍາລັບການຍົກຕົວຢ່າງ), ຫຼັງຈາກນັ້ນພວກເຮົາຈະໄດ້ຮັບຄວາມຜິດພາດກັບຈໍານວນຂອງ DC ທີ່ຕ້ອງການ. ເພື່ອຊອກຫາທີ່ຢູ່ IP ໃດໂດຍໝາຍເລກ DC ທີ່ທ່ານຕ້ອງການເຊື່ອມຕໍ່, ຊ່ວຍພວກເຮົາ help.getConfig. ໃນເວລາຫນຶ່ງມີພຽງແຕ່ 5 ລາຍການເທົ່ານັ້ນ, ແຕ່ຫຼັງຈາກເຫດການທີ່ມີຊື່ສຽງຂອງປີ 2018, ຕົວເລກໄດ້ເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ຕອນນີ້ຂໍໃຫ້ຈື່ໄວ້ວ່າພວກເຮົາມາຮອດຂັ້ນຕອນນີ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍໂດຍບໍ່ເປີດເຜີຍຊື່. ມັນບໍ່ແພງເກີນໄປທີ່ຈະພຽງແຕ່ໄດ້ຮັບທີ່ຢູ່ IP ບໍ? ເປັນຫຍັງບໍ່ເຮັດສິ່ງນີ້, ແລະການດໍາເນີນງານອື່ນໆ, ໃນສ່ວນທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດຂອງ MTProto? ຂ້າພະເຈົ້າໄດ້ຍິນການຄັດຄ້ານ: "ພວກເຮົາຈະເຮັດແນວໃດເພື່ອໃຫ້ແນ່ໃຈວ່າມັນບໍ່ແມ່ນ RKN ຜູ້ທີ່ຈະຕອບສະຫນອງກັບທີ່ຢູ່ທີ່ບໍ່ຖືກຕ້ອງ?" ນີ້ພວກເຮົາຈື່ຈໍາວ່າ, ໂດຍທົ່ວໄປ, ລູກຄ້າຢ່າງເປັນທາງການ ກະແຈ RSA ຖືກຝັງໄວ້, i.e. ທ່ານສາມາດພຽງແຕ່ ຈອງ ຂໍ້ມູນນີ້. ຕົວຈິງແລ້ວ, ນີ້ແມ່ນໄດ້ຖືກເຮັດແລ້ວສໍາລັບຂໍ້ມູນກ່ຽວກັບການຂັດຂວາງການຂັດຂວາງທີ່ລູກຄ້າໄດ້ຮັບຜ່ານຊ່ອງທາງອື່ນ (ຕາມເຫດຜົນ, ນີ້ບໍ່ສາມາດເຮັດໄດ້ໃນ MTProto ຕົວມັນເອງ; ທ່ານຍັງຈໍາເປັນຕ້ອງຮູ້ບ່ອນທີ່ຈະເຊື່ອມຕໍ່).

ຕົກ​ລົງ. ໃນຂັ້ນຕອນຂອງການອະນຸຍາດລູກຄ້ານີ້, ພວກເຮົາຍັງບໍ່ໄດ້ອະນຸຍາດແລະບໍ່ໄດ້ລົງທະບຽນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ. ພວກເຮົາພຽງແຕ່ຕ້ອງການເບິ່ງສິ່ງທີ່ເຄື່ອງແມ່ຂ່າຍຕອບສະຫນອງຕໍ່ວິທີການທີ່ມີໃຫ້ກັບຜູ້ໃຊ້ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ແລະນີ້…

Vasily, [10.07.18 14:45] https://core.telegram.org/method/help.getConfig

config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;

https://core.telegram.org/api/datacenter

config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;

ໃນໂຄງການ, ທໍາອິດມາທີສອງ

ໃນ tdesktop schema ຄ່າທີສາມແມ່ນ

ແມ່ນແລ້ວ, ນັບຕັ້ງແຕ່ນັ້ນມາ, ແນ່ນອນ, ເອກະສານໄດ້ຖືກປັບປຸງ. ເຖິງແມ່ນວ່າມັນອາດຈະກາຍເປັນຄວາມບໍ່ກ່ຽວຂ້ອງໃນໄວໆນີ້. ນັກພັດທະນາຈົວຄວນຮູ້ແນວໃດ? ບາງທີຖ້າທ່ານລົງທະບຽນຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ພວກເຂົາຈະແຈ້ງໃຫ້ທ່ານຮູ້ບໍ? Vasily ໄດ້ເຮັດສິ່ງນີ້, ແຕ່ອະນິຈາ, ພວກເຂົາບໍ່ໄດ້ສົ່ງຫຍັງໃຫ້ລາວ (ອີກເທື່ອຫນຶ່ງ, ພວກເຮົາຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນພາກທີສອງ).

...ທ່ານສັງເກດເຫັນວ່າພວກເຮົາໄດ້ຍ້າຍໄປຫາ API ແລ້ວ, i.e. ໃນລະດັບຕໍ່ໄປ, ແລະພາດບາງສິ່ງບາງຢ່າງໃນຫົວຂໍ້ MTProto? ບໍ່ແປກໃຈ:

Vasily, [28.06.18 02:04] ມມ, ເຂົາເຈົ້າກຳລັງລົມກັນຢູ່ບາງອັນໃນ e2e.

Mtproto ກໍານົດຂັ້ນຕອນການເຂົ້າລະຫັດແລະລະຫັດສໍາລັບທັງສອງໂດເມນ, ເຊັ່ນດຽວກັນກັບໂຄງສ້າງ wrapper ເລັກນ້ອຍ.

ແຕ່ພວກມັນປະສົມລະດັບທີ່ແຕກຕ່າງກັນຂອງ stack ຢູ່ສະ ເໝີ, ສະນັ້ນມັນບໍ່ຈະແຈ້ງສະ ເໝີ ໄປວ່າ mtproto ສິ້ນສຸດລົງຢູ່ໃສແລະລະດັບຕໍ່ໄປເລີ່ມຕົ້ນ.

ພວກເຂົາເຈົ້າປະສົມແນວໃດ? ດີ, ນີ້ແມ່ນລະຫັດຊົ່ວຄາວດຽວກັນສໍາລັບ PFS, ຕົວຢ່າງ (ໂດຍວິທີທາງການ, Telegram Desktop ບໍ່ສາມາດເຮັດໄດ້). ມັນຖືກປະຕິບັດໂດຍການຮ້ອງຂໍ API auth.bindTempAuthKey, i.e. ຈາກລະດັບສູງສຸດ. ແຕ່ໃນເວລາດຽວກັນມັນແຊກແຊງການເຂົ້າລະຫັດຢູ່ໃນລະດັບຕ່ໍາ - ຫຼັງຈາກມັນ, ຕົວຢ່າງ, ທ່ານຈໍາເປັນຕ້ອງເຮັດມັນອີກເທື່ອຫນຶ່ງ. initConnection ແລະອື່ນໆ, ນີ້ບໍ່ແມ່ນ ພຽງແຕ່ ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ປົກ​ກະ​ຕິ​. ສິ່ງທີ່ພິເສດແມ່ນທ່ານສາມາດມີກະແຈຊົ່ວຄາວອັນດຽວຕໍ່ DC, ເຖິງແມ່ນວ່າພາກສະຫນາມ auth_key_id ໃນແຕ່ລະຂໍ້ຄວາມຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນຄີໄດ້ຢ່າງຫນ້ອຍທຸກໆຂໍ້ຄວາມ, ແລະເຄື່ອງແມ່ຂ່າຍມີສິດທີ່ຈະ "ລືມ" ກະແຈຊົ່ວຄາວໄດ້ທຸກເວລາ - ເອກະສານບໍ່ໄດ້ບອກວ່າຈະເຮັດແນວໃດໃນກໍລະນີນີ້ ... ດີ, ເປັນຫຍັງສາມາດເຮັດໄດ້ ເຈົ້າມີກະແຈຫຼາຍອັນ, ຄືກັບຊຸດຂອງເກືອໃນອະນາຄົດ, ແລະ?..

ມີບາງສິ່ງອື່ນໆທີ່ຄວນສັງເກດກ່ຽວກັບຫົວຂໍ້ MTProto.

ຂໍ້ຄວາມ, msg_id, msg_seqno, ການຢືນຢັນ, pings ໃນທິດທາງທີ່ບໍ່ຖືກຕ້ອງແລະ idiosyncrasies ອື່ນໆ

ເປັນຫຍັງເຈົ້າຕ້ອງຮູ້ກ່ຽວກັບພວກມັນ? ເນື່ອງຈາກວ່າພວກເຂົາ "ຮົ່ວ" ໃນລະດັບທີ່ສູງກວ່າ, ແລະທ່ານຈໍາເປັນຕ້ອງຮູ້ເຖິງພວກມັນໃນເວລາທີ່ເຮັດວຽກກັບ API. ສົມມຸດວ່າພວກເຮົາບໍ່ສົນໃຈ msg_key; ລະດັບຕ່ໍາໄດ້ຖອດລະຫັດທຸກຢ່າງສໍາລັບພວກເຮົາ. ແຕ່ພາຍໃນຂໍ້ມູນທີ່ຖືກຖອດລະຫັດພວກເຮົາມີຊ່ອງຂໍ້ມູນຕໍ່ໄປນີ້ (ຍັງຄວາມຍາວຂອງຂໍ້ມູນ, ດັ່ງນັ້ນພວກເຮົາຮູ້ວ່າບ່ອນໃດຢູ່ບ່ອນໃດ, ແຕ່ມັນບໍ່ສໍາຄັນ):

• ເກືອ - int64
• session_id - int64
• message_id — int64
• seq_no - int32

ໃຫ້ພວກເຮົາເຕືອນທ່ານວ່າມີພຽງແຕ່ເກືອຫນຶ່ງສໍາລັບ DC ທັງຫມົດ. ເປັນ​ຫຍັງ​ຈຶ່ງ​ຮູ້​ກ່ຽວ​ກັບ​ນາງ​? ບໍ່ພຽງແຕ່ເນື່ອງຈາກວ່າມີການຮ້ອງຂໍ get_future_salts, ເຊິ່ງບອກທ່ານວ່າໄລຍະໃດຈະຖືກຕ້ອງ, ແຕ່ຍັງຍ້ອນວ່າຖ້າເກືອຂອງເຈົ້າ "ເນົ່າເປື່ອຍ", ຫຼັງຈາກນັ້ນຂໍ້ຄວາມ (ຄໍາຮ້ອງຂໍ) ຈະສູນເສຍໄປ. ແນ່ນອນ, ເຄື່ອງແມ່ຂ່າຍຈະລາຍງານເກືອໃຫມ່ໂດຍການອອກ new_session_created - ແຕ່ກັບອັນເກົ່າເຈົ້າຈະຕ້ອງສົ່ງຄືນບາງອັນ, ຕົວຢ່າງ. ແລະບັນຫານີ້ມີຜົນກະທົບຕໍ່ສະຖາປັດຕະຍະກໍາຂອງແອັບພລິເຄຊັນ.

ເຊີບເວີໄດ້ຖືກອະນຸຍາດໃຫ້ຫຼຸດລົງເຊດຊັນທັງຫມົດແລະຕອບສະຫນອງດ້ວຍວິທີນີ້ດ້ວຍເຫດຜົນຫຼາຍຢ່າງ. ຕົວຈິງແລ້ວ, ກອງປະຊຸມ MTProto ແມ່ນຫຍັງຈາກຝ່າຍລູກຄ້າ? ນີ້ແມ່ນສອງຕົວເລກ session_id и seq_no ຂໍ້ຄວາມພາຍໃນເຊດຊັນນີ້. ດີ, ແລະການເຊື່ອມຕໍ່ TCP, ແນ່ນອນ. ໃຫ້ເວົ້າວ່າລູກຄ້າຂອງພວກເຮົາຍັງບໍ່ຮູ້ວິທີການເຮັດຫຼາຍຢ່າງ, ລາວໄດ້ຕັດການເຊື່ອມຕໍ່ແລະເຊື່ອມຕໍ່ໃຫມ່. ຖ້າສິ່ງນີ້ເກີດຂຶ້ນຢ່າງໄວວາ - ກອງປະຊຸມເກົ່າສືບຕໍ່ໃນການເຊື່ອມຕໍ່ TCP ໃຫມ່, ເພີ່ມຂຶ້ນ seq_no ຕື່ມອີກ. ຖ້າມັນໃຊ້ເວລາດົນ, ເຄື່ອງແມ່ຂ່າຍສາມາດລຶບມັນໄດ້, ເພາະວ່າຢູ່ຂ້າງຂອງມັນຍັງເປັນແຖວ, ດັ່ງທີ່ພວກເຮົາພົບເຫັນ.

ມັນຄວນຈະເປັນແນວໃດ seq_no? ໂອ້, ນັ້ນແມ່ນຄໍາຖາມທີ່ຫຍຸ້ງຍາກ. ພະຍາຍາມເຂົ້າໃຈຢ່າງຊື່ສັດໃນສິ່ງທີ່ຫມາຍຄວາມວ່າ:

ຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງກັບເນື້ອຫາ

ຂໍ້ຄວາມທີ່ຮຽກຮ້ອງໃຫ້ມີການຮັບຮູ້ຢ່າງຈະແຈ້ງ. ເຫຼົ່ານີ້ລວມມີຜູ້ໃຊ້ທັງຫມົດແລະຂໍ້ຄວາມການບໍລິການຈໍານວນຫຼາຍ, virtually ທັງຫມົດຍົກເວັ້ນການບັນຈຸແລະການຮັບຮູ້.

ໝາຍເລກລຳດັບຂໍ້ຄວາມ (msg_seqno)

ຈໍານວນ 32-bit ເທົ່າກັບສອງເທົ່າຂອງຈໍານວນຂໍ້ຄວາມ "ທີ່ກ່ຽວຂ້ອງກັບເນື້ອຫາ" (ທີ່ຮຽກຮ້ອງໃຫ້ມີການຮັບຮູ້, ແລະໂດຍສະເພາະທີ່ບໍ່ແມ່ນບັນຈຸ) ທີ່ສ້າງຂຶ້ນໂດຍຜູ້ສົ່ງກ່ອນຂໍ້ຄວາມນີ້ແລະຕໍ່ມາເພີ່ມຂຶ້ນຫນຶ່ງຖ້າຫາກວ່າຂໍ້ຄວາມປະຈຸບັນແມ່ນເປັນ. ຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງກັບເນື້ອຫາ. ຕູ້ຄອນເທນເນີຈະຖືກສ້າງຂື້ນເລື້ອຍໆຫຼັງຈາກເນື້ອໃນທັງຫມົດຂອງມັນ; ດັ່ງນັ້ນ, ຈໍານວນລໍາດັບຂອງມັນໃຫຍ່ກວ່າຫຼືເທົ່າກັບຕົວເລກລໍາດັບຂອງຂໍ້ຄວາມທີ່ມີຢູ່ໃນມັນ.

ວົງຈອນປະເພດໃດແດ່ທີ່ມີການເພີ່ມຂຶ້ນໂດຍ 1, ແລະຫຼັງຈາກນັ້ນອີກໂດຍ 2? .. ຂ້າພະເຈົ້າສົງໃສວ່າໃນເບື້ອງຕົ້ນພວກເຂົາຫມາຍຄວາມວ່າ "ຫນ້ອຍທີ່ສຸດສໍາລັບ ACK, ສ່ວນທີ່ເຫຼືອແມ່ນຕົວເລກ", ແຕ່ຜົນໄດ້ຮັບແມ່ນບໍ່ຄືກັນ - ໂດຍສະເພາະ, ມັນອອກມາ, ສາມາດສົ່ງໄດ້ ຫຼາຍໆຄັ້ງ ການຢືນຢັນມີຄືກັນ seq_no! ແນວໃດ? ຕົວຢ່າງເຊັ່ນ, ເຄື່ອງແມ່ຂ່າຍສົ່ງໃຫ້ພວກເຮົາບາງສິ່ງບາງຢ່າງ, ສົ່ງມັນ, ແລະພວກເຮົາເອງຍັງຄົງງຽບ, ພຽງແຕ່ຕອບສະຫນອງກັບຂໍ້ຄວາມການບໍລິການຢືນຢັນການໄດ້ຮັບຂໍ້ຄວາມຂອງມັນ. ໃນກໍລະນີນີ້, ການຢືນຢັນຂາອອກຂອງພວກເຮົາຈະມີຕົວເລກຂາອອກດຽວກັນ. ຖ້າທ່ານຄຸ້ນເຄີຍກັບ TCP ແລະຄິດວ່ານີ້ສຽງປ່າທໍາມະຊາດບາງຢ່າງ, ແຕ່ເບິ່ງຄືວ່າບໍ່ທໍາມະດາ, ເພາະວ່າໃນ TCP seq_no ບໍ່ມີການປ່ຽນແປງ, ແຕ່ການຢືນຢັນໄປ seq_no ໃນອີກດ້ານຫນຶ່ງ, ຂ້າພະເຈົ້າຈະເລັ່ງເຮັດໃຫ້ເຈົ້າເສຍໃຈ. ການຢືນຢັນແມ່ນໃຫ້ຢູ່ໃນ MTProto ບໍ່ແມ່ນ on the seq_no, ໃນ TCP, ແຕ່ໂດຍ msg_id !

ນີ້​ແມ່ນ​ຫຍັງ msg_id, ທີ່ສໍາຄັນທີ່ສຸດຂອງສາຂາເຫຼົ່ານີ້? ຕົວລະບຸຂໍ້ຄວາມທີ່ເປັນເອກະລັກ, ຕາມທີ່ຊື່ແນະນໍາ. ມັນຖືກກໍານົດເປັນຕົວເລກ 64 ບິດ, ບິດຕ່ໍາສຸດທີ່ອີກເທື່ອຫນຶ່ງມີ magic "server-not-server", ແລະສ່ວນທີ່ເຫຼືອແມ່ນການສະແຕມເວລາ Unix, ລວມທັງສ່ວນເສດເຫຼືອ, ປ່ຽນ 32 bits ໄປທາງຊ້າຍ. ເຫຼົ່ານັ້ນ. timestamp per se (ແລະຂໍ້ຄວາມທີ່ມີເວລາທີ່ແຕກຕ່າງກັນຫຼາຍເກີນໄປຈະຖືກປະຕິເສດໂດຍເຄື່ອງແມ່ຂ່າຍ). ຈາກນີ້ມັນ turns ໃຫ້ເຫັນວ່າໂດຍທົ່ວໄປນີ້ແມ່ນຕົວລະບຸທົ່ວໂລກສໍາລັບລູກຄ້າ. ໃຫ້ວ່າ - ໃຫ້ພວກເຮົາຈື່ session_id - ພວກ​ເຮົາ​ຮັບ​ປະ​ກັນ​: ພາຍໃຕ້ສະຖານະການໃດກໍ່ຕາມ, ຂໍ້ຄວາມທີ່ຫມາຍຄວາມວ່າສໍາລັບຫນຶ່ງເຊດຊັນຈະຖືກສົ່ງເຂົ້າໄປໃນເຊດຊັນອື່ນ. ນັ້ນແມ່ນ, ມັນ turns ໃຫ້ເຫັນວ່າມີແລ້ວ ສາມ ລະດັບ - ເຊດຊັນ, ຈໍານວນເຊດຊັນ, ID ຂໍ້ຄວາມ. ເປັນຫຍັງການສັບສົນດັ່ງກ່າວ, ຄວາມລຶກລັບນີ້ແມ່ນຍິ່ງໃຫຍ່ຫຼາຍ.

ດັ່ງ​ນັ້ນ msg_id ຈໍາ​ເປັນ​ສໍາ​ລັບ ...

RPC: ການຮ້ອງຂໍ, ຄໍາຕອບ, ຄວາມຜິດພາດ. ການຢືນຢັນ.

ດັ່ງທີ່ທ່ານອາດຈະໄດ້ສັງເກດເຫັນ, ບໍ່ມີປະເພດພິເສດ "ເຮັດການຮ້ອງຂໍ RPC" ຫຼືປະຕິບັດຫນ້າໃດໆໃນແຜນວາດ, ເຖິງແມ່ນວ່າມີຄໍາຕອບ. ຫຼັງຈາກທີ່ທັງຫມົດ, ພວກເຮົາມີຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງກັບເນື້ອຫາ! ນັ້ນ​ແມ່ນ, ໃດໆ ຂໍ້ຄວາມອາດຈະເປັນຄໍາຮ້ອງຂໍ! ຫຼືບໍ່ຈະເປັນ. ຫລັງ​ຈາກ​ນັ້ນ, ແຕ່ລະຄົນ ມີແມ່ນ msg_id. ແຕ່ມີຄໍາຕອບ:

rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;

ນີ້ແມ່ນບ່ອນທີ່ມັນຖືກລະບຸວ່າຂໍ້ຄວາມໃດເປັນການຕອບ. ດັ່ງນັ້ນ, ໃນລະດັບສູງສຸດຂອງ API, ທ່ານຈະຕ້ອງຈື່ຈໍາວ່າຈໍານວນຄໍາຮ້ອງຂໍຂອງທ່ານແມ່ນຫຍັງ - ຂ້າພະເຈົ້າຄິດວ່າບໍ່ຈໍາເປັນຕ້ອງອະທິບາຍວ່າການເຮັດວຽກແມ່ນ asynchronous, ແລະສາມາດມີຫຼາຍຄໍາຮ້ອງຂໍທີ່ດໍາເນີນຢູ່ໃນເວລາດຽວກັນ, ຄໍາຕອບທີ່ສາມາດໄດ້ຮັບການສົ່ງຄືນໃນຄໍາສັ່ງໃດ? ໃນຫຼັກການ, ຈາກຂໍ້ຄວາມນີ້ແລະຂໍ້ຜິດພາດທີ່ຄ້າຍຄືກັບບໍ່ມີຄົນງານ, ສະຖາປັດຕະຍະກໍາທີ່ຢູ່ເບື້ອງຫລັງນີ້ສາມາດຕິດຕາມໄດ້: ເຄື່ອງແມ່ຂ່າຍທີ່ຮັກສາການເຊື່ອມຕໍ່ TCP ກັບທ່ານແມ່ນຕົວດຸ່ນດ່ຽງດ້ານຫນ້າ, ມັນສົ່ງຕໍ່ຄໍາຮ້ອງຂໍໄປຫາ backends ແລະລວບລວມພວກເຂົາຄືນຜ່ານ. message_id. ມັນເບິ່ງຄືວ່າທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ຈະແຈ້ງ, ມີເຫດຜົນແລະດີ.

ແມ່ນແລ້ວ?.. ແລະຖ້າທ່ານຄິດກ່ຽວກັບມັນ? ຫຼັງຈາກທີ່ທັງຫມົດ, ການຕອບສະຫນອງ RPC ຕົວຂອງມັນເອງຍັງມີພາກສະຫນາມ msg_id! ພວກເຮົາຈໍາເປັນຕ້ອງຮ້ອງໃສ່ເຄື່ອງແມ່ຂ່າຍວ່າ "ເຈົ້າບໍ່ໄດ້ຕອບຄໍາຕອບຂອງຂ້ອຍ!"? ແລະແມ່ນແລ້ວ, ມີຫຍັງແດ່ກ່ຽວກັບການຢືນຢັນ? ກ່ຽວກັບຫນ້າ ຂໍ້ຄວາມກ່ຽວກັບຂໍ້ຄວາມ ບອກພວກເຮົາວ່າແມ່ນຫຍັງ

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

ແລະມັນຕ້ອງເຮັດໂດຍແຕ່ລະຝ່າຍ. ແຕ່ບໍ່ແມ່ນສະເຫມີ! ຖ້າທ່ານໄດ້ຮັບ RpcResult, ຕົວຂອງມັນເອງເຮັດຫນ້າທີ່ເປັນການຢືນຢັນ. ນັ້ນແມ່ນ, ເຄື່ອງແມ່ຂ່າຍສາມາດຕອບສະຫນອງຄໍາຮ້ອງຂໍຂອງທ່ານດ້ວຍ MsgsAck - ເຊັ່ນ, "ຂ້ອຍໄດ້ຮັບມັນ." RpcResult ສາມາດຕອບສະຫນອງໄດ້ທັນທີ. ມັນອາດຈະເປັນທັງສອງ.

ແລະແມ່ນແລ້ວ, ເຈົ້າຍັງຕ້ອງຕອບຄໍາຕອບ! ການຢືນຢັນ. ຖ້າບໍ່ດັ່ງນັ້ນ, ເຊີບເວີຈະພິຈາລະນາວ່າບໍ່ສາມາດຈັດສົ່ງໄດ້ ແລະສົ່ງຄືນໃຫ້ທ່ານອີກຄັ້ງ. ເຖິງແມ່ນວ່າຫຼັງຈາກການເຊື່ອມຕໍ່ຄືນ. ແຕ່ໃນທີ່ນີ້, ແນ່ນອນ, ບັນຫາຂອງການຫມົດເວລາເກີດຂື້ນ. ໃຫ້​ເຮົາ​ມາ​ເບິ່ງ​ເຂົາ​ເຈົ້າ​ຕໍ່​ມາ​ໜ້ອຍ​ໜຶ່ງ.

ໃນເວລານີ້, ໃຫ້ພວກເຮົາເບິ່ງຂໍ້ຜິດພາດຂອງການປະຕິບັດການສອບຖາມທີ່ເປັນໄປໄດ້.

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

ໂອ້, ບາງຄົນຈະຮ້ອງອອກມາ, ນີ້ແມ່ນຮູບແບບທີ່ມີມະນຸດຫຼາຍ - ມີເສັ້ນ! ໃຊ້​ເວ​ລາ​ຂອງ​ເຈົ້າ. ທີ່ນີ້ ບັນຊີລາຍຊື່ຂອງຄວາມຜິດພາດ, ແຕ່ແນ່ນອນບໍ່ສໍາເລັດ. ຈາກມັນພວກເຮົາຮຽນຮູ້ວ່າລະຫັດແມ່ນ ບາງສິ່ງບາງຢ່າງເຊັ່ນ: ຄວາມຜິດພາດ HTTP (ດີ, ແນ່ນອນ, semantics ຂອງການຕອບສະຫນອງບໍ່ໄດ້ຖືກເຄົາລົບ, ໃນບາງບ່ອນພວກເຂົາຖືກແຈກຢາຍແບບສຸ່ມລະຫວ່າງລະຫັດ), ແລະເສັ້ນເບິ່ງຄືວ່າ. CAPITAL_LETTERS_AND_NUMBERS. ຕົວຢ່າງ, PHONE_NUMBER_OCCUPIED ຫຼື FILE_PART_Х_MISSING. ດີ, ນັ້ນແມ່ນ, ເຈົ້າຍັງຕ້ອງການເສັ້ນນີ້ ວິເຄາະ. ຕົວຢ່າງ FLOOD_WAIT_3600 ຈະຫມາຍຄວາມວ່າທ່ານຕ້ອງລໍຖ້າຫນຶ່ງຊົ່ວໂມງ, ແລະ PHONE_MIGRATE_5, ວ່າເບີໂທລະສັບທີ່ມີຄໍານໍາຫນ້ານີ້ຕ້ອງໄດ້ຮັບການລົງທະບຽນຢູ່ໃນ 5th DC. ພວກເຮົາມີພາສາປະເພດ, ແມ່ນບໍ? ພວກ​ເຮົາ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ມີ​ການ​ໂຕ້​ຖຽງ​ຈາກ​ສະ​ຕ​ຣິງ​, ຄົນ​ປົກ​ກະ​ຕິ​ຈະ​ເຮັດ​ໄດ້​, ບໍ່​ເປັນ​ຫຍັງ​.

ອີກເທື່ອຫນຶ່ງ, ນີ້ບໍ່ແມ່ນຢູ່ໃນຫນ້າຂໍ້ຄວາມບໍລິການ, ແຕ່, ຕາມປົກກະຕິກັບໂຄງການນີ້, ຂໍ້ມູນສາມາດພົບໄດ້ ໃນໜ້າເອກະສານອື່ນ. ຫລື ຖິ້ມຄວາມສົງໃສ. ກ່ອນອື່ນ ໝົດ, ເບິ່ງ, ການລະເມີດການພິມ / ຊັ້ນ - RpcError ສາມາດຖືກຮັງຢູ່ໃນ RpcResult. ເປັນຫຍັງບໍ່ຢູ່ຂ້າງນອກ? ພວກ​ເຮົາ​ບໍ່​ໄດ້​ຄໍາ​ນ​ຶງ​ເຖິງ​ຫຍັງ​?.. ດັ່ງ​ນັ້ນ​, ການ​ຮັບ​ປະ​ກັນ​ທີ່​ຢູ່​ໃສ​ RpcError ອາດຈະບໍ່ຖືກຝັງຢູ່ໃນ RpcResult, ແຕ່ຖືກໂດຍກົງຫຼືຮັງຢູ່ໃນປະເພດອື່ນ?.. ແລະຖ້າມັນເຮັດບໍ່ໄດ້, ເປັນຫຍັງມັນຈຶ່ງບໍ່ຢູ່ໃນລະດັບສູງສຸດ, i.e. ມັນຂາດຫາຍໄປ req_msg_id ? ..

ແຕ່ໃຫ້ສືບຕໍ່ກ່ຽວກັບຂໍ້ຄວາມການບໍລິການ. ລູກຄ້າອາດຈະຄິດວ່າເຄື່ອງແມ່ຂ່າຍແມ່ນຄິດເປັນເວລາດົນນານແລະເຮັດໃຫ້ຄໍາຮ້ອງຂໍທີ່ປະເສີດນີ້:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

ມີສາມຄໍາຕອບທີ່ເປັນໄປໄດ້ສໍາລັບຄໍາຖາມນີ້, ອີກເທື່ອຫນຶ່ງຕັດກັນກັບກົນໄກການຢືນຢັນ; ພະຍາຍາມເຂົ້າໃຈສິ່ງທີ່ພວກເຂົາຄວນຈະເປັນ (ແລະສິ່ງທີ່ບັນຊີລາຍຊື່ທົ່ວໄປຂອງປະເພດທີ່ບໍ່ຕ້ອງການການຢືນຢັນ) ແມ່ນປ່ອຍໃຫ້ຜູ້ອ່ານເປັນວຽກບ້ານ (ຫມາຍເຫດ: ຂໍ້ມູນໃນ ລະຫັດແຫຼ່ງ Telegram Desktop ບໍ່ຄົບຖ້ວນ).

ການຕິດຢາເສບຕິດ: ສະຖານະພາບຂໍ້ຄວາມ

ໂດຍທົ່ວໄປແລ້ວ, ຫຼາຍໆບ່ອນໃນ TL, MTProto ແລະ Telegram ໂດຍທົ່ວໄປເຮັດໃຫ້ຄວາມຮູ້ສຶກດື້ດ້ານ, ແຕ່ອອກຈາກຄວາມສຸພາບ, ມີສະຕິປັນຍາ ແລະ ອື່ນໆ. ທັກສະອ່ອນໆ ພວກ​ເຮົາ​ໄດ້​ມິດ​ງຽບ​ກ່ຽວ​ກັບ​ເລື່ອງ​ນີ້​ຢ່າງ​ສຸພາບ, ແລະ​ໄດ້​ເຊັນ​ເຊີ​ນ​ຄວາມ​ຊົ່ວ​ຮ້າຍ​ໃນ​ການ​ສົນ​ທະ​ນາ. ຢ່າງໃດກໍຕາມ, ສະຖານທີ່ນີ້Оສ່ວນໃຫຍ່ຂອງຫນ້າແມ່ນກ່ຽວກັບ ຂໍ້ຄວາມກ່ຽວກັບຂໍ້ຄວາມ ມັນຫນ້າຕົກໃຈແມ່ນແຕ່ສໍາລັບຂ້ອຍ, ຜູ້ທີ່ເຮັດວຽກກັບໂປໂຕຄອນເຄືອຂ່າຍເປັນເວລາດົນນານແລະໄດ້ເຫັນລົດຖີບທີ່ມີລະດັບຄວາມໂກດທີ່ແຕກຕ່າງກັນ.

ມັນເລີ່ມຕົ້ນ innocuously, ດ້ວຍການຢືນຢັນ. ຕໍ່ໄປພວກເຂົາບອກພວກເຮົາກ່ຽວກັບ

bad_msg_notification#a7eff811 bad_msg_id:long bad_msg_seqno:int error_code:int = BadMsgNotification;
bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_server_salt:long = BadMsgNotification;

ດີ, ທຸກຄົນທີ່ເລີ່ມເຮັດວຽກກັບ MTProto ຈະຕ້ອງຈັດການກັບພວກເຂົາ; ໃນວົງຈອນຂອງ "ແກ້ໄຂ - ລວບລວມຄືນໃຫມ່ - ເປີດຕົວ", ການໄດ້ຮັບຄວາມຜິດພາດຂອງຕົວເລກຫຼືເກືອທີ່ມີການຄຸ້ມຄອງທີ່ບໍ່ດີໃນລະຫວ່າງການດັດແກ້ແມ່ນເປັນເລື່ອງທໍາມະດາ. ຢ່າງໃດກໍຕາມ, ມີສອງຈຸດນີ້:

1. ນີ້ຫມາຍຄວາມວ່າຂໍ້ຄວາມຕົ້ນສະບັບໄດ້ສູນເສຍໄປ. ພວກເຮົາຈໍາເປັນຕ້ອງສ້າງບາງຄິວ, ພວກເຮົາຈະເບິ່ງໃນພາຍຫຼັງ.
2. ຕົວເລກຄວາມຜິດພາດທີ່ແປກປະຫຼາດເຫຼົ່ານີ້ແມ່ນຫຍັງ? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... ຕົວເລກອື່ນຢູ່ໃສ, Tommy?

ເອກະສານລະບຸວ່າ:

ຄວາມຕັ້ງໃຈແມ່ນວ່າຄ່າ error_code ໄດ້ຖືກຈັດເປັນກຸ່ມ (error_code >> 4): ຕົວຢ່າງ, ລະຫັດ 0x40 — 0x4f ກົງກັບຄວາມຜິດພາດໃນການເສື່ອມໂຊມຂອງບັນຈຸ.

ແຕ່, ກ່ອນອື່ນ ໝົດ, ການປ່ຽນແປງໃນທິດທາງອື່ນ, ແລະອັນທີສອງ, ມັນບໍ່ ສຳ ຄັນ, ລະຫັດອື່ນຢູ່ໃສ? ໃນຫົວຂອງຜູ້ຂຽນ?.. ຢ່າງໃດກໍຕາມ, ເຫຼົ່ານີ້ແມ່ນ trifles.

ສິ່ງເສບຕິດເລີ່ມຕົ້ນໃນຂໍ້ຄວາມກ່ຽວກັບສະຖານະຂໍ້ຄວາມ ແລະສຳເນົາຂໍ້ຄວາມ:

• ຮ້ອງຂໍຂໍ້ມູນສະຖານະຂໍ້ຄວາມ
  ຖ້າຝ່າຍໃດຝ່າຍໜຶ່ງບໍ່ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບສະຖານະຂອງຂໍ້ຄວາມທີ່ສົ່ງອອກມາເປັນໄລຍະໜຶ່ງ, ມັນອາດຈະຮຽກຮ້ອງຈາກອີກຝ່າຍຢ່າງຈະແຈ້ງ:
  msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
• ຂໍ້​ຄວາມ​ໃຫ້​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ສະ​ຖາ​ນະ​ພາບ​ຂອງ​ຂໍ້​ຄວາມ​
  msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
  ທີ່ນີ້, info ແມ່ນສະຕຣິງທີ່ປະກອບດ້ວຍໜຶ່ງໄບຕ໌ຂອງສະຖານະຂໍ້ຄວາມທີ່ແນ່ນອນສຳລັບແຕ່ລະຂໍ້ຄວາມຈາກລາຍຊື່ msg_ids ທີ່ເຂົ້າມາ:
  • 1 = ບໍ່ມີຫຍັງຮູ້ກ່ຽວກັບຂໍ້ຄວາມ (msg_id ຕ່ໍາເກີນໄປ, ພາກສ່ວນອື່ນອາດຈະລືມມັນ)
  • 2 = ຂໍ້ຄວາມບໍ່ໄດ້ຮັບ (msg_id ຢູ່ໃນຂອບເຂດຂອງຕົວລະບຸທີ່ເກັບໄວ້; ແນວໃດກໍ່ຕາມ, ພາກສ່ວນອື່ນແນ່ນອນວ່າບໍ່ໄດ້ຮັບຂໍ້ຄວາມເຊັ່ນນັ້ນ)
  • 3 = ຂໍ້​ຄວາມ​ບໍ່​ໄດ້​ຮັບ (msg_id ສູງ​ເກີນ​ໄປ​; ແນວ​ໃດ​ກໍ​ຕາມ​, ອີກ​ຝ່າຍ​ແນ່​ນອນ​ວ່າ​ບໍ່​ໄດ້​ຮັບ​ມັນ​)
  • 4 = ຂໍ້​ຄວາມ​ທີ່​ໄດ້​ຮັບ (ໃຫ້​ສັງ​ເກດ​ວ່າ​ການ​ຕອບ​ສະ​ຫນອງ​ນີ້​ແມ່ນ​ໃນ​ເວ​ລາ​ດຽວ​ກັນ​ການ​ຮັບ​ຮູ້​ການ​ຮັບ​)
  • +8 = ຂໍ້ຄວາມໄດ້ຮັບການຍອມຮັບແລ້ວ
  • +16 = ຂໍ້ຄວາມບໍ່ຮຽກຮ້ອງໃຫ້ມີການຮັບຮູ້
  • +32 = RPC query ບັນຈຸຢູ່ໃນຂໍ້ຄວາມທີ່ກໍາລັງດໍາເນີນການຫຼືການປຸງແຕ່ງສໍາເລັດແລ້ວ
  • +64 = ການຕອບໂຕ້ທີ່ກ່ຽວຂ້ອງກັບເນື້ອຫາຕໍ່ກັບຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນແລ້ວ
  • +128 = ພາກສ່ວນອື່ນຮູ້ຄວາມຈິງວ່າຂໍ້ຄວາມໄດ້ຮັບແລ້ວ
    ຄໍາຕອບນີ້ບໍ່ຮຽກຮ້ອງໃຫ້ມີການຮັບຮູ້. ມັນເປັນການຮັບຮູ້ຂອງ msgs_state_req ທີ່ກ່ຽວຂ້ອງ, ໃນຕົວຂອງມັນເອງ.
    ໃຫ້ສັງເກດວ່າຖ້າມັນປາກົດຂື້ນຢ່າງກະທັນຫັນວ່າອີກຝ່າຍບໍ່ມີຂໍ້ຄວາມທີ່ເບິ່ງຄືວ່າມັນຖືກສົ່ງໄປຫາມັນ, ຂໍ້ຄວາມສາມາດຖືກສົ່ງຄືນໃຫມ່. ເຖິງແມ່ນວ່າອີກຝ່າຍຄວນໄດ້ຮັບສອງສະບັບຂອງຂໍ້ຄວາມໃນເວລາດຽວກັນ, ຊໍ້າກັນຈະຖືກລະເລີຍ. (ຖ້າເວລາຫຼາຍເກີນໄປ, ແລະ msg_id ຕົ້ນສະບັບບໍ່ຖືກຕ້ອງ, ຂໍ້ຄວາມຈະຖືກຫໍ່ດ້ວຍ msg_copy).
• ການສື່ສານແບບສະໝັກໃຈຂອງສະຖານະຂອງຂໍ້ຄວາມ
  ຝ່າຍໃດຝ່າຍໜຶ່ງອາດສະໝັກໃຈແຈ້ງໃຫ້ຝ່າຍອື່ນຮູ້ສະຖານະຂອງຂໍ້ຄວາມທີ່ສົ່ງໂດຍຝ່າຍອື່ນ.
  msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
• ຂະຫຍາຍການສື່ສານແບບສະໝັກໃຈຂອງສະຖານະຂອງຂໍ້ຄວາມດຽວ
  ...
  msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
• ການຮ້ອງຂໍຢ່າງຈະແຈ້ງເພື່ອສົ່ງຂໍ້ຄວາມຄືນໃໝ່
  msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
  ຝ່າຍ​ຫ່າງ​ໄກ​ສອກ​ຫຼີກ​ໄດ້​ຕອບ​ສະ​ຫນອງ​ໃນ​ທັນ​ທີ​ໂດຍ​ການ​ສົ່ງ​ຄືນ​ຂໍ້​ຄວາມ​ທີ່​ຮ້ອງ​ຂໍ […]
• ການຮ້ອງຂໍຢ່າງຈະແຈ້ງເພື່ອສົ່ງຄໍາຕອບຄືນ
  msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
  ພາກສ່ວນຫ່າງໄກສອກຫຼີກຕອບທັນທີໂດຍການສົ່ງຄືນ ຄໍາຕອບ ກັບຂໍ້ຄວາມທີ່ຮ້ອງຂໍ […]
• ສຳເນົາຂໍ້ຄວາມ
  ໃນບາງສະຖານະການ, ຂໍ້ຄວາມເກົ່າທີ່ມີ msg_id ທີ່ບໍ່ມີຄວາມຖືກຕ້ອງຈໍາເປັນຕ້ອງຖືກສົ່ງຄືນໃຫມ່. ຫຼັງຈາກນັ້ນ, ມັນຖືກຫໍ່ຢູ່ໃນຖັງສໍາເນົາ:
  msg_copy#e06046b2 orig_message:Message = MessageCopy;
  ເມື່ອໄດ້ຮັບ, ຂໍ້ຄວາມຈະຖືກປຸງແຕ່ງຄືກັບວ່າ wrapper ບໍ່ຢູ່ທີ່ນັ້ນ. ຢ່າງໃດກໍຕາມ, ຖ້າມັນເປັນທີ່ຮູ້ຈັກຢ່າງແນ່ນອນວ່າຂໍ້ຄວາມ orig_message.msg_id ໄດ້ຖືກຮັບ, ຫຼັງຈາກນັ້ນຂໍ້ຄວາມໃຫມ່ບໍ່ໄດ້ດໍາເນີນການ (ໃນຂະນະທີ່ໃນເວລາດຽວກັນ, ມັນແລະ orig_message.msg_id ໄດ້ຮັບການຍອມຮັບ). ຄ່າຂອງ orig_message.msg_id ຕ້ອງຕໍ່າກວ່າ msg_id ຂອງກ່ອງບັນຈຸ.

ໃຫ້ຂອງແມ້ແຕ່ຮັກສາງຽບກ່ຽວກັບສິ່ງທີ່ msgs_state_info ອີກເທື່ອຫນຶ່ງ, ຫູຂອງ TL ທີ່ບໍ່ສໍາເລັດແມ່ນຕິດອອກ (ພວກເຮົາຕ້ອງການ vector ຂອງ bytes, ແລະໃນສອງ bits ຕ່ໍາມີ enum, ແລະໃນສອງ bits ສູງມີທຸງ). ຈຸດແມ່ນແຕກຕ່າງກັນ. ມີໃຜເຂົ້າໃຈວ່າເປັນຫຍັງທັງຫມົດນີ້ແມ່ນຢູ່ໃນການປະຕິບັດ? ໃນລູກຄ້າທີ່ແທ້ຈິງ ຈໍາເປັນ?.. ມັນເປັນເລື່ອງຍາກ, ແຕ່ຄົນເຮົາສາມາດຈິນຕະນາການຜົນປະໂຫຍດບາງຢ່າງຖ້າບຸກຄົນໃດຫນຶ່ງມີສ່ວນຮ່ວມໃນການດີບັກ, ແລະໃນຮູບແບບການໂຕ້ຕອບ - ຖາມເຄື່ອງແມ່ຂ່າຍວ່າແນວໃດແລະແນວໃດ. ແຕ່ໃນທີ່ນີ້ຄໍາຮ້ອງຂໍໄດ້ຖືກອະທິບາຍ ໄປ​ກັບ.

ມັນປະຕິບັດຕາມວ່າແຕ່ລະຝ່າຍຕ້ອງບໍ່ພຽງແຕ່ເຂົ້າລະຫັດແລະສົ່ງຂໍ້ຄວາມເທົ່ານັ້ນ, ແຕ່ຍັງເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບຕົວເອງ, ກ່ຽວກັບການຕອບສະຫນອງຕໍ່ພວກເຂົາ, ເປັນເວລາທີ່ບໍ່ຮູ້ຈັກ. ເອກະສານບໍ່ໄດ້ອະທິບາຍເຖິງເວລາ ຫຼື ການປະຕິບັດຕົວຈິງຂອງຄຸນສົມບັດເຫຼົ່ານີ້. ບໍ່ມີທາງໃດ. ສິ່ງທີ່ຫນ້າປະຫລາດໃຈທີ່ສຸດແມ່ນວ່າພວກເຂົາຖືກນໍາໃຊ້ຕົວຈິງໃນລະຫັດຂອງລູກຄ້າຢ່າງເປັນທາງການ! ປາກົດຂື້ນວ່າພວກເຂົາຖືກບອກບາງສິ່ງບາງຢ່າງທີ່ບໍ່ໄດ້ລວມຢູ່ໃນເອກະສານສາທາລະນະ. ເຂົ້າໃຈຈາກລະຫັດ ເປັນຫຍັງ, ແມ່ນບໍ່ງ່າຍດາຍຄືໃນກໍລະນີຂອງ TL - ມັນບໍ່ແມ່ນ (ຂ້ອນຂ້າງ) ສ່ວນທີ່ໂດດດ່ຽວຢ່າງມີເຫດຜົນ, ແຕ່ເປັນຊິ້ນສ່ວນທີ່ຕິດກັບສະຖາປັດຕະຍະກໍາຄໍາຮ້ອງສະຫມັກ, i.e. ຈະຕ້ອງໃຊ້ເວລາຫຼາຍກວ່າເກົ່າເພື່ອເຂົ້າໃຈລະຫັດຄໍາຮ້ອງສະຫມັກ.

Pings ແລະເວລາ. ຄິວ.

ຈາກທຸກສິ່ງທຸກຢ່າງ, ຖ້າພວກເຮົາຈື່ຈໍາການຄາດເດົາກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງເຊີຟເວີ (ການແຈກຢາຍຄໍາຮ້ອງຂໍໃນທົ່ວ backends), ເປັນສິ່ງທີ່ຫນ້າເສົ້າໃຈຫຼາຍປະຕິບັດຕາມ - ເຖິງວ່າຈະມີການຮັບປະກັນການຈັດສົ່ງທັງຫມົດໃນ TCP (ຂໍ້ມູນຈະຖືກສົ່ງ, ຫຼືທ່ານຈະໄດ້ຮັບແຈ້ງກ່ຽວກັບຊ່ອງຫວ່າງ, ແຕ່. ຂໍ້​ມູນ​ຈະ​ໄດ້​ຮັບ​ການ​ສົ່ງ​ກ່ອນ​ທີ່​ບັນ​ຫາ​ຈະ​ເກີດ​ຂຶ້ນ​)​, ການ​ຢືນ​ຢັນ​ໃນ MTProto ຕົວ​ມັນ​ເອງ - ບໍ່ມີການຮັບປະກັນ. ເຄື່ອງແມ່ຂ່າຍສາມາດສູນເສຍຫຼືຖິ້ມຂໍ້ຄວາມຂອງເຈົ້າໄດ້ງ່າຍ, ແລະບໍ່ມີຫຍັງສາມາດເຮັດໄດ້ກ່ຽວກັບມັນ, ພຽງແຕ່ໃຊ້ໄມ້ຄ້ອນປະເພດຕ່າງໆ.

ແລະທໍາອິດຂອງການທັງຫມົດ - ແຖວຂໍ້ຄວາມ. ດີ, ມີສິ່ງຫນຶ່ງທີ່ທຸກສິ່ງທຸກຢ່າງເຫັນໄດ້ຊັດເຈນຕັ້ງແຕ່ເລີ່ມຕົ້ນ - ຂໍ້ຄວາມທີ່ບໍ່ໄດ້ຮັບການຢືນຢັນຕ້ອງຖືກເກັບໄວ້ແລະ reent. ແລະຫຼັງຈາກເວລາໃດ? ແລະ jester ຮູ້ຈັກພຣະອົງ. ບາງທີຂໍ້ຄວາມທີ່ຕິດຂັດເຫຼົ່ານັ້ນແກ້ໄຂບັນຫານີ້ດ້ວຍໄມ້ຄ້ອນເທົ້າ, ເວົ້າວ່າ, ໃນ Telegram Desktop ມີປະມານ 4 ຄິວທີ່ສອດຄ້ອງກັນກັບພວກເຂົາ (ບາງທີອາດມີຫຼາຍກວ່ານັ້ນ, ດັ່ງທີ່ໄດ້ກ່າວມາແລ້ວ, ສໍາລັບເລື່ອງນີ້, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈລະຫັດແລະສະຖາປັດຕະຍະກໍາຂອງມັນຢ່າງຈິງຈັງ; ໃນເວລາດຽວກັນ. ເວລາ, ພວກເຮົາຮູ້ວ່າມັນບໍ່ສາມາດຖືກນໍາມາເປັນຕົວຢ່າງ; ຈໍານວນບາງປະເພດຈາກໂຄງການ MTProto ບໍ່ໄດ້ຖືກນໍາໃຊ້ໃນມັນ).

ເປັນຫຍັງເລື່ອງນີ້ເກີດຂຶ້ນ? ອາດຈະເປັນ, ຜູ້ຂຽນໂປລແກລມເຊີຟເວີບໍ່ສາມາດຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືພາຍໃນກຸ່ມ, ຫຼືແມ້ກະທັ້ງ buffering ໃນຕົວດຸ່ນດ່ຽງດ້ານຫນ້າ, ແລະໂອນບັນຫານີ້ໃຫ້ກັບລູກຄ້າ. ອອກຈາກຄວາມສິ້ນຫວັງ, Vasily ພະຍາຍາມປະຕິບັດທາງເລືອກທາງເລືອກ, ມີພຽງແຕ່ສອງຄິວ, ການນໍາໃຊ້ສູດການຄິດໄລ່ຈາກ TCP - ການວັດແທກ RTT ກັບເຄື່ອງແມ່ຂ່າຍແລະການປັບຂະຫນາດຂອງ "ປ່ອງຢ້ຽມ" (ໃນຂໍ້ຄວາມ) ຂຶ້ນກັບຈໍານວນຄໍາຮ້ອງຂໍທີ່ບໍ່ໄດ້ຮັບການຢືນຢັນ. ນັ້ນແມ່ນ, ລັກສະນະທີ່ຫຍາບຄາຍສໍາລັບການປະເມີນການໂຫຼດຂອງເຄື່ອງແມ່ຂ່າຍແມ່ນຈໍານວນຄໍາຮ້ອງຂໍຂອງພວກເຮົາທີ່ມັນສາມາດ chew ໃນເວລາດຽວກັນແລະບໍ່ສູນເສຍ.

ແລ້ວ, ນັ້ນແມ່ນ, ເຈົ້າເຂົ້າໃຈ, ແມ່ນບໍ? ຖ້າທ່ານຕ້ອງປະຕິບັດ TCP ອີກເທື່ອຫນຶ່ງຢູ່ເທິງໂປໂຕຄອນທີ່ແລ່ນຜ່ານ TCP, ນີ້ຊີ້ໃຫ້ເຫັນເຖິງໂປໂຕຄອນທີ່ຖືກອອກແບບບໍ່ດີຫຼາຍ.

ໂອ້, ເປັນຫຍັງທ່ານຕ້ອງການຫຼາຍກວ່າຫນຶ່ງຄິວ, ແລະນີ້ຫມາຍຄວາມວ່າແນວໃດສໍາລັບຄົນທີ່ເຮັດວຽກກັບ API ລະດັບສູງ? ເບິ່ງ, ທ່ານເຮັດການຮ້ອງຂໍ, serialize ມັນ, ແຕ່ເລື້ອຍໆທ່ານບໍ່ສາມາດສົ່ງມັນທັນທີ. ເປັນຫຍັງ? ເນື່ອງຈາກວ່າຄໍາຕອບຈະເປັນ msg_id, ຊຶ່ງເປັນຊົ່ວຄາວаຂ້ອຍເປັນປ້າຍຊື່, ການມອບຫມາຍທີ່ຖືກເລື່ອນທີ່ດີທີ່ສຸດຈົນກ່ວາຊ້າເທົ່າທີ່ເປັນໄປໄດ້ - ໃນກໍລະນີທີ່ເຄື່ອງແມ່ຂ່າຍປະຕິເສດມັນເນື່ອງຈາກເວລາບໍ່ກົງກັນລະຫວ່າງພວກເຮົາກັບລາວ (ແນ່ນອນ, ພວກເຮົາສາມາດເຮັດໄມ້ຄ້ອນທີ່ປ່ຽນເວລາຂອງພວກເຮົາຈາກປະຈຸບັນ. ກັບເຄື່ອງແມ່ຂ່າຍໂດຍການເພີ່ມ delta ທີ່ຄິດໄລ່ຈາກການຕອບສະຫນອງຂອງເຄື່ອງແມ່ຂ່າຍ - ລູກຄ້າທີ່ເປັນທາງການເຮັດແນວນີ້, ແຕ່ວ່າມັນແມ່ນ crude ແລະບໍ່ຖືກຕ້ອງເນື່ອງຈາກ buffering). ດັ່ງນັ້ນ, ເມື່ອທ່ານຮ້ອງຂໍດ້ວຍການໂທຫາຫນ້າທີ່ທ້ອງຖິ່ນຈາກຫ້ອງສະຫມຸດ, ຂໍ້ຄວາມຈະຜ່ານຂັ້ນຕອນຕໍ່ໄປນີ້:

1. ມັນຢູ່ໃນແຖວດຽວແລະລໍຖ້າການເຂົ້າລະຫັດ.
2. ແຕ່ງຕັ້ງ msg_id ແລະຂໍ້ຄວາມໄດ້ໄປຫາແຖວອື່ນ - ການສົ່ງຕໍ່ທີ່ເປັນໄປໄດ້; ສົ່ງໄປທີ່ເຕົ້າຮັບ.
3. a) ເຊີບເວີຕອບ MsgsAck - ຂໍ້ຄວາມຖືກສົ່ງ, ພວກເຮົາລຶບມັນອອກຈາກ "ແຖວອື່ນ".
   b) ຫຼືໃນທາງກັບກັນ, ລາວບໍ່ມັກບາງສິ່ງບາງຢ່າງ, ລາວຕອບ badmsg - ສົ່ງຄືນຈາກ "ແຖວອື່ນ"
   c) ບໍ່ມີຫຍັງທີ່ຮູ້ຈັກ, ຂໍ້ຄວາມຕ້ອງໄດ້ຮັບການ resent ຈາກແຖວອື່ນ - ແຕ່ມັນບໍ່ຮູ້ຈັກແນ່ນອນໃນເວລາໃດ.
4. ສຸດທ້າຍເຄື່ອງແມ່ຂ່າຍຕອບສະຫນອງ RpcResult - ການຕອບສະຫນອງຕົວຈິງ (ຫຼືຄວາມຜິດພາດ) - ບໍ່ພຽງແຕ່ສົ່ງ, ແຕ່ຍັງດໍາເນີນການ.

ອາດຈະເປັນ, ການນໍາໃຊ້ຕູ້ຄອນເທນເນີສາມາດແກ້ໄຂບັນຫາໄດ້ບາງສ່ວນ. ນີ້ແມ່ນເວລາທີ່ຊໍ່ຂອງຂໍ້ຄວາມຖືກບັນຈຸເຂົ້າໄປໃນຫນຶ່ງ, ແລະເຄື່ອງແມ່ຂ່າຍຕອບສະຫນອງດ້ວຍການຢືນຢັນກັບພວກເຂົາທັງຫມົດໃນເວລາດຽວກັນ, ໃນຫນຶ່ງ. msg_id. ແຕ່ລາວຍັງຈະປະຕິເສດຊຸດນີ້, ຖ້າມີບາງຢ່າງຜິດພາດ, ທັງຫມົດ.

ແລະໃນຈຸດນີ້, ການພິຈາລະນາທີ່ບໍ່ແມ່ນທາງວິຊາການເຂົ້າມາມີບົດບາດ. ຈາກປະສົບການ, ພວກເຮົາໄດ້ເຫັນໄມ້ຄ້ອນເທົ້າຫຼາຍຢ່າງ, ແລະນອກຈາກນັ້ນ, ໃນປັດຈຸບັນພວກເຮົາຈະເຫັນຕົວຢ່າງຂອງຄໍາແນະນໍາທີ່ບໍ່ດີແລະສະຖາປັດຕະຍະກໍາຫຼາຍກວ່າເກົ່າ - ໃນເງື່ອນໄຂດັ່ງກ່າວ, ມັນຄຸ້ມຄ່າທີ່ຈະໄວ້ວາງໃຈແລະການຕັດສິນໃຈດັ່ງກ່າວບໍ? ຄໍາຖາມແມ່ນ rhetorical (ແນ່ນອນບໍ່ແມ່ນ).

ພວກເຮົາເວົ້າກ່ຽວກັບຫຍັງ? ຖ້າຢູ່ໃນຫົວຂໍ້ຂອງ "ຂໍ້ຄວາມກ່ຽວກັບຢາເສບຕິດ" ເຈົ້າຍັງສາມາດຄາດເດົາໄດ້ດ້ວຍການຄັດຄ້ານເຊັ່ນ: "ເຈົ້າໂງ່, ເຈົ້າບໍ່ເຂົ້າໃຈແຜນການທີ່ດີຂອງພວກເຮົາ!" (ດັ່ງນັ້ນ, ຂຽນເອກະສານກ່ອນ, ຕາມທີ່ຄົນທໍາມະດາຄວນ, ດ້ວຍເຫດຜົນແລະຕົວຢ່າງຂອງການແລກປ່ຽນຊຸດ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະສົນທະນາ), ເວລາ / ເວລາຫມົດເວລາແມ່ນຄໍາຖາມທີ່ປະຕິບັດໄດ້ຢ່າງແທ້ຈິງແລະສະເພາະ, ທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ແມ່ນເປັນທີ່ຮູ້ຈັກເປັນເວລາດົນນານ. ເອກະສານບອກຫຍັງພວກເຮົາກ່ຽວກັບການໝົດເວລາ?

ເຄື່ອງແມ່ຂ່າຍມັກຈະຮັບຮູ້ການໄດ້ຮັບຂໍ້ຄວາມຈາກລູກຄ້າ (ຕາມປົກກະຕິ, ການສອບຖາມ RPC) ໂດຍໃຊ້ການຕອບສະຫນອງ RPC. ຖ້າການຕອບສະ ໜອງ ເປັນເວລາດົນນານ, ເຄື່ອງແມ່ຂ່າຍອາດຈະສົ່ງການຮັບຮູ້ການຮັບ, ແລະຕໍ່ມາ, ການຕອບສະ ໜອງ ຂອງ RPC ເອງ.

ລູກຄ້າປົກກະຕິຮັບຮູ້ການໄດ້ຮັບຂໍ້ຄວາມຈາກເຄື່ອງແມ່ຂ່າຍ (ໂດຍປົກກະຕິ, ຄໍາຕອບ RPC) ໂດຍການເພີ່ມການຮັບຮູ້ກັບຄໍາຖາມ RPC ຕໍ່ໄປຖ້າມັນບໍ່ໄດ້ສົ່ງຊ້າເກີນໄປ (ຖ້າມັນຖືກສ້າງ, ໃຫ້ເວົ້າວ່າ, 60-120 ວິນາທີຫຼັງຈາກໄດ້ຮັບ. ຂໍ້ຄວາມຈາກເຊີບເວີ). ຢ່າງໃດກໍຕາມ, ຖ້າເປັນເວລາດົນນານ, ບໍ່ມີເຫດຜົນທີ່ຈະສົ່ງຂໍ້ຄວາມໄປຫາເຄື່ອງແມ່ຂ່າຍຫຼືຖ້າມີຈໍານວນຂໍ້ຄວາມທີ່ບໍ່ໄດ້ຮັບການຍອມຮັບຈາກເຄື່ອງແມ່ຂ່າຍ (ເວົ້າວ່າ, ຫຼາຍກວ່າ 16), ລູກຄ້າສົ່ງການຮັບຮູ້ແບບຢືນຢູ່ຄົນດຽວ.

... ຂ້ອຍແປວ່າ: ຕົວເຮົາເອງບໍ່ຮູ້ວ່າພວກເຮົາຕ້ອງການມັນຫຼາຍປານໃດ, ສະນັ້ນໃຫ້ສົມມຸດວ່າໃຫ້ມັນເປັນແບບນີ້.

ແລະ​ກ່ຽວ​ກັບ pings​:

ຂໍ້ຄວາມ Ping (PING/PONG)

ping#7abe77ec ping_id:long = Pong;

ການຕອບສະ ໜອງ ໂດຍປົກກະຕິແມ່ນກັບຄືນສູ່ການເຊື່ອມຕໍ່ດຽວກັນ:

pong#347773c5 msg_id:long ping_id:long = Pong;

ຂໍ້ຄວາມເຫຼົ່ານີ້ບໍ່ຮຽກຮ້ອງໃຫ້ມີການຮັບຮູ້. ປອງຖືກສົ່ງພຽງແຕ່ໃນການຕອບໂຕ້ກັບ ping ໃນຂະນະທີ່ ping ສາມາດເລີ່ມຕົ້ນໄດ້ໂດຍທັງສອງຂ້າງ.

ການເລື່ອນການເຊື່ອມຕໍ່ປິດ + PING

ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

ເຮັດວຽກຄືກັບ ping. ນອກຈາກນັ້ນ, ຫຼັງຈາກໄດ້ຮັບອັນນີ້ແລ້ວ, ເຊີບເວີເລີ່ມຈັບເວລາທີ່ຈະປິດການເຊື່ອມຕໍ່ປັດຈຸບັນ disconnect_delay ວິນາທີຕໍ່ມາ ເວັ້ນເສຍແຕ່ວ່າມັນຈະໄດ້ຮັບຂໍ້ຄວາມໃຫມ່ຂອງປະເພດດຽວກັນທີ່ຕັ້ງເວລາທັງຫມົດທີ່ຜ່ານມາໂດຍອັດຕະໂນມັດ. ຖ້າລູກຄ້າສົ່ງ ping ເຫຼົ່ານີ້ທຸກໆ 60 ວິນາທີ, ຕົວຢ່າງ, ມັນອາດຈະກໍານົດ disconnect_delay ເທົ່າກັບ 75 ວິນາທີ.

ເຈົ້າ​ເປັນ​ບ້າ​ຫວາ?! ໃນ 60 ວິນາທີ, ລົດໄຟຈະເຂົ້າໄປໃນສະຖານີ, ລຸດລົງແລະເອົາຜູ້ໂດຍສານ, ແລະອີກເທື່ອຫນຶ່ງສູນເສຍການຕິດຕໍ່ໃນອຸໂມງ. ໃນ 120 ວິນາທີ, ໃນຂະນະທີ່ທ່ານໄດ້ຍິນມັນ, ມັນຈະມາຮອດອີກອັນຫນຶ່ງ, ແລະການເຊື່ອມຕໍ່ອາດຈະແຕກ. ແລ້ວ, ມັນເປັນທີ່ຊັດເຈນວ່າຂາມາຈາກໃສ - "ຂ້ອຍໄດ້ຍິນສຽງດັງ, ແຕ່ບໍ່ຮູ້ວ່າມັນຢູ່ໃສ", ມີລະບົບຂອງ Nagl ແລະທາງເລືອກ TCP_NODELAY, ມີຈຸດປະສົງສໍາລັບການເຮັດວຽກແບບໂຕ້ຕອບ. ແຕ່, excuse ຂ້າພະເຈົ້າ, ຖືສຸດຄ່າເລີ່ມຕົ້ນຂອງມັນ - 200 ມິນລີວິນາທີ ຖ້າທ່ານຕ້ອງການພັນລະນາບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນແລະປະຫຍັດສອງສາມແພັກເກັດທີ່ເປັນໄປໄດ້, ຫຼັງຈາກນັ້ນໃຫ້ປິດມັນໄວ້ 5 ວິນາທີ, ຫຼືໃດກໍ່ຕາມ "ຜູ້ໃຊ້ກໍາລັງພິມ ... " ຂໍ້ຄວາມຫມົດເວລາໃນປັດຈຸບັນ. ແຕ່ບໍ່ມີອີກແລ້ວ.

ແລະສຸດທ້າຍ, pings. ນັ້ນແມ່ນ, ການກວດສອບຊີວິດຂອງການເຊື່ອມຕໍ່ TCP. ມັນເປັນເລື່ອງຕະຫລົກ, ແຕ່ປະມານ 10 ປີກ່ອນຫນ້ານີ້ຂ້າພະເຈົ້າໄດ້ຂຽນຂໍ້ຄວາມທີ່ສໍາຄັນກ່ຽວກັບຜູ້ສົ່ງຂ່າວຂອງຫໍພັກຂອງຄະນະວິຊາຂອງພວກເຮົາ - ຜູ້ຂຽນຢູ່ທີ່ນັ້ນຍັງໄດ້ ping ເຄື່ອງແມ່ຂ່າຍຈາກລູກຄ້າ, ແລະບໍ່ກົງກັນຂ້າມ. ແຕ່ນັກສຶກສາປີ 3 ເປັນສິ່ງຫນຶ່ງ, ແລະຫ້ອງການສາກົນແມ່ນອີກ, ບໍ່ແມ່ນບໍ?..

ຫນ້າທໍາອິດ, ໂຄງການການສຶກສາເລັກນ້ອຍ. ການເຊື່ອມຕໍ່ TCP, ໃນກໍລະນີທີ່ບໍ່ມີການແລກປ່ຽນແພັກເກັດ, ສາມາດມີຊີວິດຢູ່ໄດ້ຫຼາຍອາທິດ. ນີ້ແມ່ນທັງດີແລະບໍ່ດີ, ຂຶ້ນກັບຈຸດປະສົງ. ມັນດີຖ້າທ່ານມີການເຊື່ອມຕໍ່ SSH ເປີດກັບເຄື່ອງແມ່ຂ່າຍ, ທ່ານໄດ້ລຸກຂຶ້ນຈາກຄອມພິວເຕີ, reboot router, ກັບຄືນໄປຫາສະຖານທີ່ຂອງທ່ານ - ເຊດຊັນຜ່ານເຄື່ອງແມ່ຂ່າຍນີ້ບໍ່ໄດ້ຖືກຈີກ (ທ່ານບໍ່ໄດ້ພິມຫຍັງ, ບໍ່ມີແພັກເກັດ) , ມັນສະດວກ. ມັນບໍ່ດີຖ້າມີລູກຄ້າຫລາຍພັນຄົນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ, ແຕ່ລະຄົນໃຊ້ຊັບພະຍາກອນ (ສະບາຍດີ, Postgres!), ແລະເຈົ້າພາບຂອງລູກຄ້າອາດຈະ rebooted ເປັນເວລາດົນນານກ່ອນຫນ້ານີ້ - ແຕ່ພວກເຮົາຈະບໍ່ຮູ້ກ່ຽວກັບມັນ.

ລະບົບສົນທະນາ / IM ຕົກຢູ່ໃນກໍລະນີທີສອງສໍາລັບເຫດຜົນເພີ່ມເຕີມຫນຶ່ງ - ສະຖານະພາບອອນໄລນ໌. ຖ້າຜູ້ໃຊ້ "ລົ້ມລົງ", ທ່ານຈໍາເປັນຕ້ອງແຈ້ງໃຫ້ຜູ້ຕິດຕໍ່ຂອງລາວກ່ຽວກັບເລື່ອງນີ້. ຖ້າບໍ່ດັ່ງນັ້ນ, ທ່ານຈະສິ້ນສຸດດ້ວຍຄວາມຜິດພາດທີ່ຜູ້ສ້າງ Jabber ໄດ້ເຮັດ (ແລະແກ້ໄຂສໍາລັບ 20 ປີ) - ຜູ້ໃຊ້ໄດ້ຕັດການເຊື່ອມຕໍ່, ແຕ່ພວກເຂົາຍັງສືບຕໍ່ຂຽນຂໍ້ຄວາມຫາລາວ, ເຊື່ອວ່າລາວອອນໄລນ໌ (ເຊິ່ງຍັງສູນເສຍທັງຫມົດໃນສິ່ງເຫຼົ່ານີ້. ສອງສາມນາທີກ່ອນທີ່ຈະຕັດການເຊື່ອມຕໍ່ໄດ້ຖືກຄົ້ນພົບ). ບໍ່, ທາງເລືອກ TCP_KEEPALIVE, ເຊິ່ງຫຼາຍຄົນທີ່ບໍ່ເຂົ້າໃຈວິທີການຈັບເວລາ TCP ເຮັດວຽກແບບສຸ່ມ (ໂດຍການກໍານົດຄ່າທໍາມະຊາດເຊັ່ນສິບວິນາທີ), ຈະບໍ່ຊ່ວຍຢູ່ທີ່ນີ້ - ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າບໍ່ພຽງແຕ່ OS kernel ເທົ່ານັ້ນ. ເຄື່ອງຈັກຂອງຜູ້ໃຊ້ແມ່ນມີຊີວິດຢູ່, ແຕ່ຍັງເຮັດວຽກປົກກະຕິ, ສາມາດຕອບສະຫນອງໄດ້, ແລະແອັບພລິເຄຊັນຕົວມັນເອງ (ທ່ານຄິດວ່າມັນບໍ່ສາມາດແຊ່ແຂໍງໄດ້ບໍ? Telegram Desktop ໃນ Ubuntu 18.04 froze ສໍາລັບຂ້ອຍຫຼາຍກວ່າຫນຶ່ງຄັ້ງ).

ນັ້ນແມ່ນເຫດຜົນທີ່ເຈົ້າຕ້ອງ ping server ລູກຄ້າ, ແລະບໍ່ກົງກັນຂ້າມ - ຖ້າລູກຄ້າເຮັດແບບນີ້, ຖ້າການເຊື່ອມຕໍ່ຖືກທໍາລາຍ, ping ຈະບໍ່ຖືກສົ່ງ, ເປົ້າຫມາຍຈະບໍ່ບັນລຸ.

ພວກເຮົາເຫັນຫຍັງຢູ່ໃນ Telegram? ມັນກົງກັນຂ້າມແທ້ໆ! ດີ, ນັ້ນແມ່ນ. ຢ່າງເປັນທາງການ, ແນ່ນອນ, ທັງສອງຝ່າຍສາມາດ ping ເຊິ່ງກັນແລະກັນ. ໃນທາງປະຕິບັດ, ລູກຄ້າໃຊ້ໄມ້ຄ້ອນເທົ້າ ping_delay_disconnect, ເຊິ່ງກໍານົດເວລາໃນເຄື່ອງແມ່ຂ່າຍ. ດີ, ຂໍໂທດ, ມັນບໍ່ຂຶ້ນກັບລູກຄ້າທີ່ຈະຕັດສິນໃຈວ່າລາວຕ້ອງການອາໄສຢູ່ທີ່ນັ້ນດົນປານໃດໂດຍບໍ່ມີການ ping. ເຄື່ອງແມ່ຂ່າຍ, ໂດຍອີງໃສ່ການໂຫຼດຂອງມັນ, ຮູ້ດີກວ່າ. ແຕ່, ແນ່ນອນ, ຖ້າທ່ານບໍ່ສົນໃຈຊັບພະຍາກອນ, ຫຼັງຈາກນັ້ນທ່ານຈະເປັນ Pinocchio ທີ່ຊົ່ວຮ້າຍຂອງເຈົ້າເອງ, ແລະໄມ້ຄ້ອນເທົ້າຈະເຮັດ ...

ມັນຄວນຈະຖືກອອກແບບແນວໃດ?

ຂ້າພະເຈົ້າເຊື່ອວ່າຂໍ້ເທັດຈິງຂ້າງເທິງຊີ້ໃຫ້ເຫັນເຖິງຄວາມສາມາດທີ່ບໍ່ສູງຫຼາຍຂອງທີມງານ Telegram / VKontakte ໃນຂົງເຂດການຂົນສົ່ງ (ແລະລະດັບຕ່ໍາ) ຂອງເຄືອຂ່າຍຄອມພິວເຕີແລະຄຸນສົມບັດທີ່ຕໍ່າໃນເລື່ອງທີ່ກ່ຽວຂ້ອງ.

ເປັນຫຍັງມັນຈຶ່ງເຮັດໃຫ້ສັບສົນຫຼາຍ, ແລະນັກສະຖາປະນິກ Telegram ພະຍາຍາມຄັດຄ້ານແນວໃດ? ຄວາມຈິງທີ່ວ່າພວກເຂົາພະຍາຍາມເຮັດກອງປະຊຸມທີ່ລອດຊີວິດການຢຸດການເຊື່ອມຕໍ່ TCP, i.e., ສິ່ງທີ່ບໍ່ໄດ້ສົ່ງໃນປັດຈຸບັນ, ພວກເຮົາຈະສົ່ງຕໍ່ມາ. ພວກເຂົາອາດຈະພະຍາຍາມເຮັດການຂົນສົ່ງ UDP, ແຕ່ພວກເຂົາປະສົບກັບຄວາມຫຍຸ້ງຍາກແລະປະຖິ້ມມັນ (ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າເອກະສານຫວ່າງເປົ່າ - ບໍ່ມີຫຍັງທີ່ຈະເວົ້າໂອ້ອວດ). ແຕ່ເນື່ອງຈາກການຂາດຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການເຄືອຂ່າຍໂດຍທົ່ວໄປແລະ TCP ໂດຍສະເພາະເຮັດວຽກ, ບ່ອນທີ່ທ່ານສາມາດອີງໃສ່ມັນ, ແລະບ່ອນທີ່ທ່ານຕ້ອງການເຮັດມັນເອງ (ແລະວິທີການ), ແລະຄວາມພະຍາຍາມທີ່ຈະສົມທົບກັບ cryptography "ສອງນົກກັບ. ຫີນກ້ອນດຽວ”, ນີ້ແມ່ນຜົນໄດ້ຮັບ.

ມັນເປັນສິ່ງຈໍາເປັນແນວໃດ? ອີງໃສ່ຄວາມຈິງທີ່ວ່າ msg_id ເປັນການປະທັບຕາເວລາທີ່ຈໍາເປັນຈາກຈຸດການເຂົ້າລະຫັດລັບເພື່ອປ້ອງກັນການໂຈມຕີ replay, ມັນເປັນຄວາມຜິດພາດທີ່ຈະແນບຟັງຊັນຕົວລະບຸທີ່ເປັນເອກະລັກກັບມັນ. ດັ່ງນັ້ນ, ໂດຍບໍ່ມີການປ່ຽນແປງພື້ນຖານຂອງສະຖາປັດຕະຍະກໍາໃນປະຈຸບັນ (ເມື່ອການຖ່າຍທອດການປັບປຸງ, ນັ້ນແມ່ນຫົວຂໍ້ API ລະດັບສູງສໍາລັບພາກສ່ວນອື່ນຂອງຊຸດນີ້), ຫນຶ່ງຈະຕ້ອງ:

1. ເຊີບເວີທີ່ຖືການເຊື່ອມຕໍ່ TCP ກັບລູກຄ້າຮັບຜິດຊອບ - ຖ້າມັນໄດ້ອ່ານຈາກຊັອກເກັດ, ກະລຸນາຮັບຮູ້, ດໍາເນີນການຫຼືສົ່ງຄືນຂໍ້ຜິດພາດ, ບໍ່ມີການສູນເສຍ. ຫຼັງຈາກນັ້ນ, ການຢືນຢັນບໍ່ແມ່ນ vector ຂອງ ids, ແຕ່ພຽງແຕ່ "seq_no ທີ່ໄດ້ຮັບສຸດທ້າຍ" - ພຽງແຕ່ຕົວເລກ, ເຊັ່ນດຽວກັບ TCP (ສອງຕົວເລກ - seq ຂອງທ່ານແລະຫນຶ່ງທີ່ຢືນຢັນ). ພວກເຮົາຢູ່ໃນກອງປະຊຸມສະເຫມີ, ບໍ່ແມ່ນບໍ?
2. ເວລາເພື່ອປ້ອງກັນການໂຈມຕີ replay ກາຍເປັນພາກສະຫນາມແຍກຕ່າງຫາກ, a la nonce. ມັນໄດ້ຖືກກວດສອບ, ແຕ່ບໍ່ມີຜົນກະທົບຫຍັງອີກ. ພຽງພໍແລະ uint32 - ຖ້າເກືອຂອງພວກເຮົາປ່ຽນແປງຢ່າງຫນ້ອຍທຸກໆເຄິ່ງມື້, ພວກເຮົາສາມາດຈັດສັນ 16 bits ໃຫ້ກັບ bits ຕ່ໍາຂອງຈໍານວນເຕັມຂອງເວລາໃນປະຈຸບັນ, ສ່ວນທີ່ເຫຼືອ - ເປັນສ່ວນເສດເຫຼືອຂອງວິນາທີ (ໃນປັດຈຸບັນ).
3. ລຶບອອກແລ້ວ msg_id ທັງຫມົດ - ຈາກທັດສະນະຂອງການຈໍາແນກການຮ້ອງຂໍໃນ backends, ມີ, ທໍາອິດ, id ລູກຄ້າ, ແລະອັນທີສອງ, session id, concatenate ໃຫ້ເຂົາເຈົ້າ. ຕາມ​ນັ້ນ​ແລ້ວ, ພຽງ​ແຕ່​ສິ່ງ​ດຽວ​ເທົ່າ​ນັ້ນ​ແມ່ນ​ພຽງ​ພໍ​ເປັນ​ຕົວ​ລະບຸ​ການ​ຮ້ອງ​ຂໍ seq_no.

ນີ້ບໍ່ແມ່ນທາງເລືອກທີ່ປະສົບຜົນສໍາເລັດຫຼາຍທີ່ສຸດ; ແບບສຸ່ມທີ່ສົມບູນສາມາດເປັນຕົວລະບຸ - ນີ້ແມ່ນເຮັດແລ້ວໃນ API ລະດັບສູງໃນເວລາສົ່ງຂໍ້ຄວາມ, ໂດຍວິທີທາງການ. ມັນຈະເປັນການດີກວ່າທີ່ຈະສ້າງສະຖາປັດຕະຍະກໍາຄືນໃຫມ່ຢ່າງສົມບູນຈາກພີ່ນ້ອງກັບຢ່າງແທ້ຈິງ, ແຕ່ນີ້ແມ່ນຫົວຂໍ້ສໍາລັບພາກສ່ວນອື່ນ, ບໍ່ແມ່ນການຕອບນີ້.

API?

ຕາດຳ! ດັ່ງນັ້ນ, ໂດຍໄດ້ຕໍ່ສູ້ກັບເສັ້ນທາງທີ່ເຕັມໄປດ້ວຍຄວາມເຈັບປວດແລະໄມ້ຄ້ອນເທົ້າ, ໃນທີ່ສຸດພວກເຮົາສາມາດສົ່ງຄໍາຮ້ອງຂໍໃດໆໄປຫາເຄື່ອງແມ່ຂ່າຍແລະໄດ້ຮັບຄໍາຕອບໃດໆກັບພວກເຂົາ, ເຊັ່ນດຽວກັນກັບໄດ້ຮັບການປັບປຸງຈາກເຄື່ອງແມ່ຂ່າຍ (ບໍ່ແມ່ນການຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງຂໍ, ແຕ່ມັນເອງ. ສົ່ງໃຫ້ພວກເຮົາ, ເຊັ່ນ PUSH, ຖ້າໃຜມັນຈະແຈ້ງກວ່ານັ້ນ).

ເອົາໃຈໃສ່, ໃນປັດຈຸບັນຈະມີຕົວຢ່າງດຽວໃນ Perl ໃນບົດຄວາມ! (ສໍາລັບຜູ້ທີ່ບໍ່ຄຸ້ນເຄີຍກັບ syntax, ການໂຕ້ຖຽງທໍາອິດຂອງພອນແມ່ນໂຄງສ້າງຂໍ້ມູນຂອງວັດຖຸ, ອັນທີສອງແມ່ນຫ້ອງຮຽນຂອງມັນ):

2019.10.24 12:00:51 $1 = {
'cb' => 'TeleUpd::__ANON__',
'out' => bless( {
'filter' => bless( {}, 'Telegram::ChannelMessagesFilterEmpty' ),
'channel' => bless( {
'access_hash' => '-6698103710539760874',
'channel_id' => '1380524958'
}, 'Telegram::InputPeerChannel' ),
'pts' => '158503',
'flags' => 0,
'limit' => 0
}, 'Telegram::Updates::GetChannelDifference' ),
'req_id' => '6751291954012037292'
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'req_msg_id' => '6751291954012037292',
'result' => bless( {
'pts' => 158508,
'flags' => 3,
'final' => 1,
'new_messages' => [],
'users' => [],
'chats' => [
bless( {
'title' => 'Хулиномика',
'username' => 'hoolinomics',
'flags' => 8288,
'id' => 1380524958,
'access_hash' => '-6698103710539760874',
'broadcast' => 1,
'version' => 0,
'photo' => bless( {
'photo_small' => bless( {
'volume_id' => 246933270,
'file_reference' => '
'secret' => '1854156056801727328',
'local_id' => 228648,
'dc_id' => 2
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'local_id' => 228650,
'file_reference' => '
'secret' => '1275570353387113110',
'volume_id' => 246933270
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1531221081
}, 'Telegram::Channel' )
],
'timeout' => 300,
'other_updates' => [
bless( {
'pts_count' => 0,
'message' => bless( {
'post' => 1,
'id' => 852,
'flags' => 50368,
'views' => 8013,
'entities' => [
bless( {
'length' => 20,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 18,
'offset' => 480,
'url' => 'https://alexeymarkov.livejournal.com/[url_вырезан].html'
}, 'Telegram::MessageEntityTextUrl' )
],
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'text' => '???? 165',
'data' => 'send_reaction_0'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 9'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'message' => 'А вот и новая книга! 
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
напечатаю.',
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571724559,
'edit_date' => 1571907562
}, 'Telegram::Message' ),
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'message' => bless( {
'edit_date' => 1571907589,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571807301,
'message' => 'Почему Вы считаете Facebook плохой компанией? Можете прокомментировать? По-моему, это шикарная компания. Без долгов, с хорошей прибылью, а если решат дивы платить, то и еще могут нехило подорожать.
Для меня ответ совершенно очевиден: потому что Facebook делает ужасный по качеству продукт. Да, у него монопольное положение и да, им пользуется огромное количество людей. Но мир не стоит на месте. Когда-то владельцам Нокии было смешно от первого Айфона. Они думали, что лучше Нокии ничего быть не может и она навсегда останется самым удобным, красивым и твёрдым телефоном - и доля рынка это красноречиво демонстрировала. Теперь им не смешно.
Конечно, рептилоиды сопротивляются напору молодых гениев: так Цукербергом был пожран Whatsapp, потом Instagram. Но всё им не пожрать, Паша Дуров не продаётся!
Так будет и с Фейсбуком. Нельзя всё время делать говно. Кто-то когда-то сделает хороший продукт, куда всё и уйдут.
#соцсети #facebook #акции #рептилоиды',
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 452'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'text' => '???? 21',
'data' => 'send_reaction_1'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'entities' => [
bless( {
'length' => 199,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 8,
'offset' => 919
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 928,
'length' => 9
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 6,
'offset' => 938
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 11,
'offset' => 945
}, 'Telegram::MessageEntityHashtag' )
],
'views' => 6964,
'flags' => 50368,
'id' => 854,
'post' => 1
}, 'Telegram::Message' ),
'pts_count' => 0
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'message' => bless( {
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 213'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 8'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 2940,
'entities' => [
bless( {
'length' => 609,
'offset' => 348
}, 'Telegram::MessageEntityItalic' )
],
'flags' => 50368,
'post' => 1,
'id' => 857,
'edit_date' => 1571907636,
'date' => 1571902479,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'message' => 'Пост про 1С вызвал бурную полемику. Человек 10 (видимо, 1с-программистов) единодушно написали:
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
Я бы добавил, что блестящая у 1С дистрибуция, а маркетинг... ну, такое.'
}, 'Telegram::Message' ),
'pts_count' => 0,
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'pts_count' => 0,
'message' => bless( {
'message' => 'Здравствуйте, расскажите, пожалуйста, чем вредит экономике 1С?
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
#софт #it #экономика',
'edit_date' => 1571907650,
'date' => 1571893707,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'flags' => 50368,
'post' => 1,
'id' => 856,
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 360'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 32'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 4416,
'entities' => [
bless( {
'offset' => 0,
'length' => 64
}, 'Telegram::MessageEntityBold' ),
bless( {
'offset' => 1551,
'length' => 5
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 3,
'offset' => 1557
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 1561,
'length' => 10
}, 'Telegram::MessageEntityHashtag' )
]
}, 'Telegram::Message' )
}, 'Telegram::UpdateEditChannelMessage' )
]
}, 'Telegram::Updates::ChannelDifference' )
}, 'MTProto::RpcResult' )
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'update' => bless( {
'user_id' => 2507460,
'status' => bless( {
'was_online' => 1571907651
}, 'Telegram::UserStatusOffline' )
}, 'Telegram::UpdateUserStatus' ),
'date' => 1571907650
}, 'Telegram::UpdateShort' )
};
2019.10.24 12:05:46 $1 = {
'in' => bless( {
'chats' => [],
'date' => 1571907946,
'seq' => 0,
'updates' => [
bless( {
'max_id' => 141719,
'channel_id' => 1295963795
}, 'Telegram::UpdateReadChannelInbox' )
],
'users' => []
}, 'Telegram::Updates' )
};
2019.10.24 13:01:23 $1 = {
'in' => bless( {
'server_salt' => '4914425622822907323',
'unique_id' => '5297282355827493819',
'first_msg_id' => '6751307555044380692'
}, 'MTProto::NewSessionCreated' )
};
2019.10.24 13:24:21 $1 = {
'in' => bless( {
'chats' => [
bless( {
'username' => 'freebsd_ru',
'version' => 0,
'flags' => 5440,
'title' => 'freebsd_ru',
'min' => 1,
'photo' => bless( {
'photo_small' => bless( {
'local_id' => 328733,
'volume_id' => 235140688,
'dc_id' => 2,
'file_reference' => '
'secret' => '4426006807282303416'
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'file_reference' => '
'volume_id' => 235140688,
'local_id' => 328735,
'secret' => '71251192991540083'
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1461248502,
'id' => 1038300508,
'democracy' => 1,
'megagroup' => 1
}, 'Telegram::Channel' )
],
'users' => [
bless( {
'last_name' => 'Panov',
'flags' => 1048646,
'min' => 1,
'id' => 82234609,
'status' => bless( {}, 'Telegram::UserStatusRecently' ),
'first_name' => 'Dima'
}, 'Telegram::User' )
],
'seq' => 0,
'date' => 1571912647,
'updates' => [
bless( {
'pts' => 137596,
'message' => bless( {
'flags' => 256,
'message' => 'Создать джейл с именем покороче ??',
'to_id' => bless( {
'channel_id' => 1038300508
}, 'Telegram::PeerChannel' ),
'id' => 119634,
'date' => 1571912647,
'from_id' => 82234609
}, 'Telegram::Message' ),
'pts_count' => 1
}, 'Telegram::UpdateNewChannelMessage' )
]
}, 'Telegram::Updates' )
};

ແມ່ນແລ້ວ, ບໍ່ແມ່ນການຫຼອກລວງດ້ວຍຈຸດປະສົງ - ຖ້າທ່ານຍັງບໍ່ໄດ້ອ່ານມັນ, ສືບຕໍ່ເດີນຫນ້າແລະເຮັດມັນ!

ໂອ້ ວ້າວ~~... ອັນນີ້ເບິ່ງຄືແນວໃດ? ບາງສິ່ງບາງຢ່າງທີ່ຄຸ້ນເຄີຍ ... ບາງທີນີ້ແມ່ນໂຄງສ້າງຂໍ້ມູນຂອງ Web API ປົກກະຕິໃນ JSON, ຍົກເວັ້ນວ່າຊັ້ນຮຽນຍັງຕິດກັບວັດຖຸ?..

ສະນັ້ນມັນເປັນແນວໃດມັນ turns ອອກ ... ມັນທັງຫມົດກ່ຽວກັບ, comrades?.. ຄວາມພະຍາຍາມຫຼາຍ - ແລະພວກເຮົາຢຸດເຊົາການພັກຜ່ອນບ່ອນທີ່ນັກຂຽນໂປລແກລມເວັບ. ພຽງແຕ່ເລີ່ມຕົ້ນ?..ບໍ່ພຽງແຕ່ JSON ຜ່ານ HTTPS ຈະງ່າຍກວ່າບໍ?! ພວກເຮົາໄດ້ຮັບຫຍັງໃນການແລກປ່ຽນ? ຄວາມພະຍາຍາມຄຸ້ມຄ່າບໍ?

ມາປະເມີນສິ່ງທີ່ TL+MTProto ມອບໃຫ້ພວກເຮົາ ແລະທາງເລືອກທີ່ເປັນໄປໄດ້ແນວໃດ. ດີ, HTTP, ເຊິ່ງສຸມໃສ່ຮູບແບບການຕອບສະຫນອງຄໍາຮ້ອງຂໍ, ແມ່ນເຫມາະສົມທີ່ບໍ່ດີ, ແຕ່ຢ່າງຫນ້ອຍບາງສິ່ງບາງຢ່າງຢູ່ເທິງ TLS?

serialization ຫນາແຫນ້ນ. ເບິ່ງໂຄງສ້າງຂໍ້ມູນນີ້, ຄ້າຍຄືກັນກັບ JSON, ຂ້ອຍຈື່ໄດ້ວ່າມີລຸ້ນ binary ຂອງມັນ. ໃຫ້ຫມາຍ MsgPack ເປັນການຂະຫຍາຍບໍ່ພຽງພໍ, ແຕ່ມີ, ຕົວຢ່າງ, CBOR - ໂດຍວິທີທາງການ, ມາດຕະຖານທີ່ອະທິບາຍໄວ້ໃນ. RFC 7049. ມັນເປັນທີ່ຫນ້າສັງເກດສໍາລັບຄວາມຈິງທີ່ວ່າມັນກໍານົດ ແທັກ, ເປັນກົນໄກການຂະຫຍາຍ, ແລະໃນບັນດາ ໄດ້ມາດຕະຖານແລ້ວ ມີໃຫ້:

• 25 + 256 - ການປ່ຽນສາຍທີ່ຊ້ໍາກັນດ້ວຍການອ້າງອີງເຖິງຈໍານວນເສັ້ນ, ເຊັ່ນວິທີການບີບອັດລາຄາຖືກ
• 26 - serialized Perl object ທີ່ມີຊື່ຫ້ອງຮຽນ ແລະ constructor arguments
• 27 - serialized language-independent object with type name and constructor arguments

ດີ, ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມ serialize ຂໍ້ມູນດຽວກັນໃນ TL ແລະໃນ CBOR ດ້ວຍການເປີດສາຍແລະການຫຸ້ມຫໍ່ວັດຖຸ. ຜົນໄດ້ຮັບເລີ່ມແຕກຕ່າງກັນໃນເງື່ອນໄຂຂອງ CBOR ບາງບ່ອນຈາກ megabyte:

cborlen=1039673 tl_len=1095092

ດັ່ງ​ນັ້ນ ສະຫຼຸບ: ມີຮູບແບບທີ່ງ່າຍກວ່າຫຼາຍທີ່ບໍ່ຂຶ້ນກັບບັນຫາຂອງ synchronization ລົ້ມເຫຼວ ຫຼືຕົວລະບຸທີ່ບໍ່ຮູ້ຈັກ, ມີປະສິດທິພາບປຽບທຽບ.

ການ​ສ້າງ​ຕັ້ງ​ການ​ເຊື່ອມ​ຕໍ່​ໄວ​. ນີ້ຫມາຍຄວາມວ່າສູນ RTT ຫຼັງຈາກການເຊື່ອມຕໍ່ຄືນໃຫມ່ (ເມື່ອຄີໄດ້ຖືກສ້າງແລ້ວຄັ້ງດຽວ) - ສາມາດນໍາໃຊ້ໄດ້ຈາກຂໍ້ຄວາມ MTProto ທໍາອິດ, ແຕ່ວ່າມີການຈອງບາງ - ມົນຕີເກືອດຽວກັນ, ເຊດຊັນບໍ່ rotten, ແລະອື່ນໆ. TLS ສະເໜີຫຍັງໃຫ້ພວກເຮົາແທນ? ອ້າງເຖິງຫົວຂໍ້:

ເມື່ອໃຊ້ PFS ໃນ TLS, TLS session tickets (RFC 5077) ເພື່ອສືບຕໍ່ເຊດຊັນທີ່ເຂົ້າລະຫັດໄວ້ໂດຍບໍ່ມີການເຈລະຈາຄືນໃຫມ່ ແລະບໍ່ມີການເກັບຮັກສາຂໍ້ມູນທີ່ສໍາຄັນຢູ່ໃນເຊີບເວີ. ເມື່ອເປີດການເຊື່ອມຕໍ່ທໍາອິດແລະສ້າງລະຫັດ, ເຄື່ອງແມ່ຂ່າຍຈະເຂົ້າລະຫັດສະຖານະການເຊື່ອມຕໍ່ແລະສົ່ງມັນໄປຫາລູກຄ້າ (ໃນຮູບແບບຂອງປີ້ກອງປະຊຸມ). ດັ່ງນັ້ນ, ເມື່ອການເຊື່ອມຕໍ່ຄືນໃຫມ່, ລູກຄ້າສົ່ງຕົ໋ວກອງປະຊຸມ, ລວມທັງລະຫັດເຊດຊັນ, ກັບຄືນໄປຫາເຄື່ອງແມ່ຂ່າຍ. ປີ້ຕົວມັນເອງຖືກເຂົ້າລະຫັດດ້ວຍກະແຈຊົ່ວຄາວ (ລະຫັດປີ້ເຊດຊັນ), ເຊິ່ງຖືກເກັບໄວ້ໃນເຊີບເວີ ແລະຕ້ອງໄດ້ຮັບການແຈກຢາຍໃນບັນດາເຊີບເວີດ້ານໜ້າທັງໝົດທີ່ປະມວນຜົນ SSL ໃນການແກ້ໄຂກຸ່ມ.[10]. ດັ່ງນັ້ນ, ການແນະນໍາຂອງຕົ໋ວກອງປະຊຸມອາດຈະລະເມີດ PFS ຖ້າກະແຈເຊີບເວີຖືກທໍາລາຍ, ຕົວຢ່າງ, ເມື່ອພວກມັນຖືກເກັບໄວ້ເປັນເວລາດົນນານ (OpenSSL, nginx, Apache ເກັບຮັກສາພວກມັນໂດຍຄ່າເລີ່ມຕົ້ນສໍາລັບໄລຍະເວລາທັງຫມົດຂອງໂຄງການ; ເວັບໄຊທ໌ທີ່ນິຍົມໃຊ້. ກຸນແຈເປັນເວລາຫຼາຍຊົ່ວໂມງ, ເຖິງມື້).

ທີ່ນີ້ RTT ບໍ່ແມ່ນສູນ, ທ່ານຈໍາເປັນຕ້ອງແລກປ່ຽນຢ່າງຫນ້ອຍ ClientHello ແລະ ServerHello, ຫຼັງຈາກນັ້ນລູກຄ້າສາມາດສົ່ງຂໍ້ມູນພ້ອມກັບ Finished. ແຕ່ໃນທີ່ນີ້ພວກເຮົາຄວນຈື່ໄວ້ວ່າພວກເຮົາບໍ່ມີເວັບ, ມີຊໍ່ຂອງການເຊື່ອມຕໍ່ທີ່ເປີດໃຫມ່, ແຕ່ messenger, ການເຊື່ອມຕໍ່ທີ່ມັກຈະເປັນຫນຶ່ງແລະຫຼາຍຫຼືຫນ້ອຍ, ຍາວ, ການຮ້ອງຂໍສັ້ນກັບຫນ້າເວັບ - ທຸກສິ່ງທຸກຢ່າງແມ່ນ multiplexed. ພາຍໃນ. ນັ້ນແມ່ນ, ມັນເປັນທີ່ຍອມຮັບໄດ້ຫຼາຍຖ້າພວກເຮົາບໍ່ໄດ້ພົບກັບພາກສ່ວນລົດໄຟໃຕ້ດິນທີ່ບໍ່ດີແທ້ໆ.

ລືມອັນອື່ນບໍ? ຂຽນໃນຄໍາເຫັນ.

ຕິດ​ຕາມ​ຕອນ​ຕໍ່​ໄປ!

ໃນພາກທີສອງຂອງຫົວຂໍ້ນີ້ພວກເຮົາຈະພິຈາລະນາບໍ່ແມ່ນດ້ານວິຊາການ, ແຕ່ບັນຫາຂອງອົງການຈັດຕັ້ງ - ວິທີການ, ອຸດົມການ, ການໂຕ້ຕອບ, ທັດສະນະຄະຕິຕໍ່ຜູ້ໃຊ້, ແລະອື່ນໆ. ຢ່າງໃດກໍຕາມ, ອີງຕາມຂໍ້ມູນດ້ານວິຊາການທີ່ນໍາສະເຫນີຢູ່ທີ່ນີ້.

ສ່ວນທີສາມຈະສືບຕໍ່ວິເຄາະອົງປະກອບດ້ານວິຊາການ / ປະສົບການການພັດທະນາ. ທ່ານຈະໄດ້ຮຽນຮູ້, ໂດຍສະເພາະ:

• ການສືບຕໍ່ຂອງ pandemonium ທີ່ມີຄວາມຫລາກຫລາຍຂອງປະເພດ TL
• ສິ່ງທີ່ບໍ່ຮູ້ກ່ຽວກັບຊ່ອງທາງ ແລະກຸ່ມໃຫຍ່
• ເປັນຫຍັງກ່ອງໂຕ້ຕອບຈຶ່ງຮ້າຍແຮງກວ່າບັນຊີລາຍການ
• ກ່ຽວ​ກັບ​ການ​ແກ້​ໄຂ​ຂໍ້​ຄວາມ​ທີ່​ສົມ​ບູນ​ແລະ​ພີ່​ນ້ອງ​ກັນ​
• ຄວາມແຕກຕ່າງລະຫວ່າງຮູບພາບແລະຮູບພາບແມ່ນຫຍັງ
• emoji ແຊກແຊງຂໍ້ຄວາມຕົວອຽງແນວໃດ

ແລະໄມ້ຄ້ອນເທົ້າອື່ນໆ! ຕິດຕາມຢູ່!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com