Temurin-build: تحميل بطيء للغاية. ماذا عن تقاسم السيول لتجنيب النطاق الترددي؟

تم إنشاؤها على ٢٧ أكتوبر ٢٠١٩  ·  42تعليقات  ·  مصدر: adoptium/temurin-build

محاولة تنزيل OpenJDK 11 ، 174 ميجابايت بسرعة 20 كيلوبايت / ثانية ، يقدر بساعتين. يبطئ أكثر (10 كيلوبايت / ثانية) أثناء المحاولة.

يتم توفير LibreOffice عبر التورنت. قد يكون مفيدًا لهذا المشروع أيضًا إذا كان النطاق الترددي يمثل مشكلة بالنسبة لك.

invalid

التعليق الأكثر فائدة

اعتماد تنزيلات OpenJDK بطيئة جدًا أيضًا عبر اتصال DSL بسعة 50 ميجابايت (ألمانيا - Deutsche Telekom VDSL ، تعمل بشكل مثالي عادةً بسرعة تزيد عن 5 ميجابايت / ثانية dl). عادةً ما أحصل على 30-50 كيلوبايت / ثانية - لذلك يستغرق تنزيل OpenJDK النموذجي أكثر من ساعة.
أفترض أن هذه مشكلة بين شركة Deutsche Telekom و Amazon (و "telia.net" وفقًا لتتبع نظام الشبكة الذي يربط بينهما).

خادم التنزيل المستخدم هو
52.216.161.35 (github-production-release-asset-2e65be.s3.amazonaws.com) وفقًا لبعض أدوات تعقب مواقع IP ، يقع عنوان IP هذا في فرجينيا (الولايات المتحدة الأمريكية). يتم نقل البيانات عبر IPv4.

ال 42 كومينتر

تتم استضافة الإصدارات على GitHub (مثل https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.5٪2B10/OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10.tar.gz). يقوم GitHub بتخزينها وتوزيعها باستخدام Amazon S3. لذلك من غير المحتمل أن تكون مشكلة في المنبع. لقد قمت للتو بتنزيل tarball المذكورة أعلاه مع 5،07 ميجابايت / ثانية.

ما زلت أقوم بتنزيل برنامج تثبيت Windows x64 MSI مترجم مسبقًا ، ما يقرب من 30 من 174 ميجابايت حتى الآن ... بسرعة 5 كيلوبايت / ثانية الآن.

34.3 ميغابايت ... توقف التنزيل. يعرض المتصفح أقل من 1 كيلوبايت / ثانية.

34.3 ميغابايت ... توقف التنزيل. يعرض المتصفح أقل من 1 كيلوبايت / ثانية.

ينزل المنجم في حوالي 65 ثانية ، وأظن أن لديك مشكلة محلية.

في هذه الحالة ، يجب أن ألقي باللوم على شركة Deutsche Telekom ... أريد أن يكون اتصالاً زائفًا بالنطاق العريض في المناطق الريفية.

@ LigH-de أنا آسف لأن التنزيلات الخاصة بك بطيئة ، ولكن حتى الآن لا يوجد ما يشير إلى أن المشكلة في صالحنا. حالة GitHub وحالة AWS كلها خضراء أيضًا. إذا كنت تريد مساعدة لتشخيص مشكلتك ، فيرجى تقديم مسار التتبع على الأقل.

تحدث هذه المشكلات عادةً بسبب زيادة سعة منافذ التبديل في نقطة عبور معينة ، إما بسبب توجيه الكثير من حركة المرور في الاتجاه الخاطئ (يمكن إصلاحه عن طريق تغيير جدول التوجيه) أو لأن بعض مزودي خدمة الإنترنت رخيص جدًا بحيث لا يمكنهم ترقية منافذ التناظر أو الشراء المزيد من سعة العبور. على أي حال ، فإن أفضل رهان لك هو تقديم شكوى إلى ISP و GitHub (بهذا الترتيب). هم في وضع يسمح لهم بالمساعدة. وفر لهم مسار تتبع على الأقل.

شكرا لك. إنها بالتأكيد قضية زمنية. دائمًا في نفس الأوقات تقريبًا ، تصبح بعض الخدمات غير موثوقة (على سبيل المثال ، تستمر تدفقات Twitch في المماطلة ، وإزالة المزامنة ، وفصل الاتصال) ، ولا تتضرر الخدمات الأخرى.

الآن قمت بتنزيله للتو بسرعة 2 ميغا بايت / ثانية في دقيقة واحدة.

اعتماد تنزيلات OpenJDK بطيئة جدًا أيضًا عبر اتصال DSL بسعة 50 ميجابايت (ألمانيا - Deutsche Telekom VDSL ، تعمل بشكل مثالي عادةً بسرعة تزيد عن 5 ميجابايت / ثانية dl). عادةً ما أحصل على 30-50 كيلوبايت / ثانية - لذلك يستغرق تنزيل OpenJDK النموذجي أكثر من ساعة.
أفترض أن هذه مشكلة بين شركة Deutsche Telekom و Amazon (و "telia.net" وفقًا لتتبع نظام الشبكة الذي يربط بينهما).

خادم التنزيل المستخدم هو
52.216.161.35 (github-production-release-asset-2e65be.s3.amazonaws.com) وفقًا لبعض أدوات تعقب مواقع IP ، يقع عنوان IP هذا في فرجينيا (الولايات المتحدة الأمريكية). يتم نقل البيانات عبر IPv4.

تكمن مشكلة شركة Deutsche Telekom في أنهم يريدون من مقدمي خدمات آخرين شراء خدمات الترانزيت. هذا هو السبب في أن جميع روابطهم الأخرى مشبعة وتحصل على سرعات تنزيل رديئة. أفضل شيء يمكنك القيام به هو تقديم شكوى إلى كل من DTAG و GitHub على أمل أن يبدؤا في تبادل حركة المرور عبر رابط مباشر.

لقد حصلت للتو على تنزيل يبلغ حوالي 8 ميغا بايت / ثانية. ربما تفاوضوا على شيء ما؟

تقارير مماثلة في منتدى doom9 بخصوص AviSynth + ؛ لا أعرف أي مزود خدمة إنترنت يستخدمه هذا المراسل ، لكنني أعتقد أنه يقيم في بولندا ، لذلك قد يتعين عليه المرور عبر العمود الفقري الألماني.

أحاول الاتصال بدعم جيثب بخصوص هذا الموضوع.

تقارير مماثلة في منتدى doom9 بخصوص AviSynth + ؛ لا أعرف أي مزود خدمة إنترنت يستخدمه هذا المراسل ، لكنني أعتقد أنه يقيم في بولندا ، لذلك قد يتعين عليه المرور عبر العمود الفقري الألماني.

أحاول الاتصال بدعم جيثب بخصوص هذا الموضوع.

لدي نفس الشيء نفس المزود مثلك.

نفس المشاكل هنا ، أيضا ألمانيا. المزود هو 1 & 1.

تعديل: تم إصلاح المشكلة باستخدام عنوان IP غير أوروبي.

حاولت اليوم إخطار شركة Deutsche Telekom (مع دعم الأولوية لشركتنا) بالإضافة إلى Telia. أفترض أن الاختناق يقع في مكان ما بين شبكاتهم الأساسية ...

نفس الشيء بالنسبة لي ، أنا أستخدم شركة Deutsche Telekom أيضًا. يحدث هذا مع جميع تنزيلات جيثب.

باستخدام عميل VPN الخاص بي (باستخدام عنوان IP ألماني أيضًا) يمكنني تنزيله بأقصى سرعة.

إذن هذه مشكلة مع مزود خدمة الإنترنت لدينا؟ هل هناك أي شيء يمكننا القيام به حيال ذلك؟

نفس الشيء هنا (أيضًا شركة Deutsche Telekom). لقد عملت حوله باستخدام Opera و VPN المدمج الخاص به.

لا أعرف ما إذا كان ذلك مفيدًا عندما يشتكي العديد من الأشخاص من نفس المشكلة (في بوابة الويب Telekom Kundencenter ، وليس الخط الساخن للهاتف). لكن حاول أفضل من أن تتجاهل.

نفس المشكلة هنا (Deutsche Telekom) ، شكرًا على التلميح مع Opera. سوف يشكو في دويتشه تليكوم. ومن المثير للاهتمام أيضًا أنه عبر T-Mobile (نفس الشركة).

التحميل بسرعة 44 كيلو بايت / ثانية

| ------------------------------------------------- ----------------------------------------- |
| احصاء |
| المضيف -٪ | مرسل | ريكف | أفضل | متوسط ​​| Wrst | آخر |
| ------------------------------------------------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 10.0.0.1 - 0 | 14 | 14 | 0 | 0 | 1 | 1 |
| 10.73.200.1 - 0 | 14 | 14 | 8 | 13 | 22 | 15 |
| nrth-core-2a-xe-10010-0.network.virginmedia.net - 0 | 14 | 14 | 10 | 14 | 24 | 16 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| m686-mp2.cvx1-b.lis.dial.ntli.net - 10 | 11 | 10 | 0 | 21 | 28 | 28 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| uk-lon01b-ri1-ae-25-0.aorta.net - 0 | 14 | 14 | 18 | 21 | 30 | 18 |
| ldn-b1-link.telia.net - 0 | 14 | 14 | 17 | 21 | 31 | 19 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| ffm-bb2-link.telia.net - 10 | 11 | 10 | 0 | 37 | 41 | 37 |
| ffm-b1-link.telia.net - 0 | 14 | 14 | 34 | 40 | 59 | 35 |
| github-ic-350972-ffm-b1.c.telia.net - 0 | 14 | 14 | 31 | 37 | 48 | 34 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| لا يوجد رد من المضيف - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| lb-140-82-118-4-ams.github.com - 10 | 11 | 10 | 0 | 41 | 44 | 41 |
| ________________________________________________ | ______ | ______ | ______ | ______ | ______ | ______ |

إذن ، هناك تيليا متورطة مرة أخرى ... ولكن من الصعب معرفة من يجب إلقاء اللوم عليه في هذه المعركة بين مزودي خدمة الإنترنت الأساسيين.

tpavesi هل فيرجن ميديا ​​مملوكة لشركة Liberty Global؟ يبدو Traceroute هكذا (aorta.net). Liberty Global هو الجاني سيء السمعة في هذا الصدد. شكوى لدعم العملاء.

@ LigH-de Telia هي واحدة من أكبر مزودي اتصال النقل العابر. ليس خطأهم إذا كانت الأطراف المعنية لا تريد ترقية الرابط.

فيرجن ميديا ​​مملوكة لشركة Liberty Global. كان هناك انقطاع كبير في الكهرباء في المملكة المتحدة في
الأيام القليلة الماضية بالضبط حيث ذكرت.

يوم الاثنين ، 27 أبريل 2020 الساعة 07:35 ، Andreas Ahlenstorf [email protected]
كتب:

tpavesi https://github.com/tpavesi هل فيرجن ميديا ​​مملوكة لشركة Liberty
عالمي؟ يبدو Traceroute هكذا (aorta.net). ليبرتي جلوبال هي أ
الجاني سيء السمعة في هذا الصدد. شكوى لدعم العملاء.

@ LigH-de https://github.com/LigH-de Telia هي واحدة من أكبر
مقدمي اتصال العبور. ليس ذنبهم إذا كانت الأطراف المعنية
لا تريد ترقية الرابط.

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-619759818 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAXA2GBZAA52NG53YZMUSZ3ROURR5ANCNFSM4JFRUSVA
.

بالفعل. كسر Twitch أيضًا ، لذلك كان جمهور تلك الحالة كبيرًا.

ملاحظة من المناطق الريفية بفرنسا على النحاس و 100 كيلو بايت كحد أقصى (أوه نعم).
نفس المشكلة تحاول الحصول على "AcceptOpenJDK" ... ولكن تم العثور على حل "زراعي".
إذا تركت المتصفح مفتوحًا ولم يزعج الجهاز أي إزعاج ، فإن التنزيل يفعل كما وجده الآخرون ... بضع ثوانٍ ثم ينقطع ... كرر بضع مرات حتى نسبة مئوية قليلة ثم يتعطل / يغلق / ينتهي.
ولكن .. إذا واصلت استخدام المتصفح والتنقل بين الصفحات ، فهذا يبدو أنه يعيد الوحش إلى الحياة.
اضطررت إلى تجربة ذلك عدة مرات ولكن يبدو أنه قابل للتكرار ... لأن التنزيل ينام.
لا أعرف ما إذا كان هذا مفيدًا ولكنه قد يساعد في الوقت الحالي.
Win7pro64 + Opera

تضمين التغريدة
لمعلوماتك أنني أعمل على حزمة VS Code حوالي 6٪ من المستخدمين فشلوا في تنزيل JDK بعد 3 محاولات ، وهو ليس عددًا صغيرًا. هل هناك أي فكرة لتحسينه؟

راجع للشغل ، إلى جانب مزودي خدمة الإنترنت المذكورين في التعليقات أعلاه ، مع وجود جميع مزودي خدمة الإنترنت تقريبًا في الصين ، لدينا وصول غير مستقر إلى GitHub / AWS.

المشكلة ليست نقص النطاق الترددي في المصدر. المشكلة هي الترابط المشبع بين مقدمي خدمات الإنترنت. ليس هناك الكثير الذي يمكننا القيام به طالما أننا نفوض معالجة التنزيلات إلى GitHub. نحن في مقعد الراكب إذا جاز التعبير.

هناك طرق لتحسين الوضع ، لكنها تجعل الأمور أكثر تعقيدًا وتتطلب عملاً كبيرًا وربما مالًا. المال هو أقل مشكلة ، والعمل لأننا قصير الأيدي.

الخيارات التي أراها:

  • تمرير التنزيلات عبر واجهة برمجة التطبيقات بدلاً من إعادة التوجيه إلى GitHub. يهدر الموارد على بث الثنائيات المتدفقة ، ولكن يمكن تخزينها مؤقتًا بواسطة Cloudflare. سنحتاج إلى ترخيص ICP من الصين لتخزين المحتوى مؤقتًا هناك وتمكين Cloudflare China CDN. ومع ذلك ، فإن دمج واجهة برمجة التطبيقات مع التنزيلات ليس شيئًا أريده.
  • قم بتطوير برنامج يمكنه مزامنة دليل محلي على جهاز / Azure Blob Storage مع API / GitHub (الإصدارات فقط). سيمكننا ذلك من استضافة التنزيلات بأنفسنا (ربما مرة أخرى عبر Cloudflare) وإعطاء خيار استضافة المرايا (لا يلزم ترخيص برنامج المقارنات الدولية لأن شخصًا آخر قد يستضيفها). يتطلب إدخال توقيع GPG للمجاميع الاختبارية الثنائية (يجب القيام به على أي حال). بالنسبة للصين ، انظر أعلاه. المشكلة: التأخير عند مزامنة API و GitHub والجهاز المحلي / Azure Blob Storage.
  • افعل شيئًا ذكيًا مع عمال Cloudflare. بالنسبة للصين ، انظر أعلاه.

إذا أراد شخص ما العمل عليها ، يرجى التواصل معنا.

اشكرك على المعلومات. يبدو أن الحل المثالي هو GitHub / AWS للعمل مع مزودي خدمة إنترنت مختلفين ، ثم نستفيد مجانًا 🤷.

حول المرايا ، يوجد أدناه اكتشاف ، فقط لمعلوماتك في حالة ما إذا كانت مفيدة.
مرآة تستضيفها جامعة تسينغهوا في الصين: https://mirrors.tuna.tsinghua.edu.cn/AdoptOpenJDK/
والتذكرة الأصلية لها. (باللغة الصينية فقط ويمكنك ترجمة الصفحة).

شكرا للرابط لتلك المرآة الصينية. https://github.com/tuna/tunasync-scripts/blob/master/adoptopenjdk.py هو البرنامج النصي الذي يستخدمونه. إن القيام بشيء من هذا القبيل هو أحد السبل المحتملة للمضي قدمًا ، ولكن كما قلت ، ولا يمكنني التأكيد على ذلك بشكل كافٍ ، يتطلب هذا التحقق من المجاميع الاختبارية وهو أمر أسهل كثيرًا مع GPG.

نفس الشيء هنا (أيضًا شركة Deutsche Telekom). لقد عملت حوله باستخدام Opera و VPN المدمج الخاص به.

نفس الشيء بالنسبة لي .. بطيء في Chrome / Opera / Edge بدون VPN
(نعم ، التنزيل الخاص بي هو عميل mqtt ، لكن صلاحيته مماثلة لـ JDK)
image

عند استخدام VPN (على سبيل المثال عميل يحمل في ثناياه عوامل Opera)
تمت زيادة التنزيل إلى 500 كيلوبايت / ثانية على الأقل
image

شكرا للتلميح مع المرآة الصينية. أسرع بكثير من استخدام تنزيل Github مباشرة

أنا أستخدم 1 & 1 (Deutsche Telekom) وما زلت أواجه نفس المشكلة.
أحصل على 1 كيلوبايت / ثانية أحيانًا :-(

أي حل لهذا؟

getashraf لقد فتحت تذكرة في Deutsche Telekom Kundenportal. بمجرد حل هذا ، سأطالب باستعادة بعض المال.
أضفت رابطًا لهذه المقالة: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

لكن توقع مكالمات من Telekom. إنهم مجبرون على الاتصال بك بشكل عشوائي سواء استمرت المشكلة أو ما إذا كنت قد تعاملت مع جهاز التوجيه الخاص بك. كما أنهم يصرون على أن لديك اتصالاً يعمل لأنهم لا يرون سوى سرعة مزامنة DSL في مكتب المساعدة.

يوجد بيان رسمي من شركة Telekom الألمانية
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Downloadgeschwindigkeiten-von-GitHub-mal-wieder-unterirdisch/td-p/3873484/page/11

لا أعرف مدى صحة هذا ، لأنه من الأسهل دائمًا القول إنه فشل خدمة أخرى.

BdT
فارماندرا

getashraf لقد فتحت تذكرة في Deutsche Telekom Kundenportal. بمجرد حل هذا ، سأطالب باستعادة بعض المال.
أضفت رابطًا لهذه المقالة: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

لكن توقع مكالمات من Telekom. إنهم مجبرون على الاتصال بك بشكل عشوائي سواء استمرت المشكلة أو ما إذا كنت قد تعاملت مع جهاز التوجيه الخاص بك. كما أنهم يصرون على أن لديك اتصالاً يعمل لأنهم لا يرون سوى سرعة مزامنة DSL في مكتب المساعدة.

تم وضع علامة على هذا الموضوع على أنه تم حله ولكنه في الواقع ليس كذلك. ما زلت أقوم بالتنزيل بحوالي 4-5 كيلوبت / ثانية وبعد وقت قصير من توقف تنزيل كل شيء. كما ورد في الرد الرسمي ليس خطأهم. لست متأكدا بشأن هذا. ومع ذلك فقد تم وضع علامة "تم حلها" ...

لست متأكدا بشأن هذا.

لماذا ا؟

لقد واجهوا مشاكل بين الحين والآخر عندما لا يواجه كل مزود آخر هذه المشكلات. بالإضافة إلى ذلك ، فهو نوع من عدم الثقة العام في دعم Telekom. المشكلات إما لم يتم حلها ويتم تمييزها على أنها تم حلها بسبب "مغادرة خاطئة" و / أو أنها تستغرق شوطًا طويلاً من خلال مستويات الدعم مع الانتظار على الهاتف لساعات. لقد عانيت من نفس المشكلة منذ بضع سنوات.

لقد واجهوا مشاكل بين الحين والآخر عندما لا يواجه كل مزود آخر هذه المشكلات. بالإضافة إلى ذلك ، فهو نوع من عدم الثقة العام في دعم Telekom. المشكلات إما لم يتم حلها ويتم تمييزها على أنها تم حلها بسبب "مغادرة خاطئة" و / أو أنها تستغرق شوطًا طويلاً من خلال مستويات الدعم مع الانتظار على الهاتف لساعات. لقد عانيت من نفس المشكلة منذ بضع سنوات.

آه ، أرى أنني أخطأت في القراءة. اعتقدت أنك ضمنيًا أن المشكلة تكمن في تبني.

التنزيل باستخدام lftp باستخدام عدة اتصالات متزامنة يساعد في تخفيف الألم قليلاً. على سبيل المثال

lftp -c "pget -c -n 20 https://github.com/mikefarah/yq/releases/download/3.4.1/yq_linux_amd64"

ومع ذلك ، فإن أوقات التنزيل لا تزال بعيدة عن المعتاد.

getashraf لقد فتحت تذكرة في Deutsche Telekom Kundenportal. بمجرد حل هذا ، سأطالب باستعادة بعض المال.
أضفت رابطًا لهذه المقالة: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

bmarwell هل سمعت منهم من قبل؟ فعلت الشيء نفسه مع "Stoerungsmeldung" لكن ذلك كان كارثة كاملة. لقد أرادوا إرسال فني إلى منزلي و / أو DSLAM "لإصلاح هذا" وعندما اتصلت مرة أخرى لإلغاء ذلك ، كان الخط الساخن جاهلاً تمامًا عندما أخبرت عن مشكلات في العمود الفقري والتي لا يمكن التحايل عليها إلا لعدم استخدام توجيه Telekom القياسي (على سبيل المثال عبر VPN) ، ثم أرادت أن تبيعني خدمة "Computerhilfe".

getashraf لقد فتحت تذكرة في Deutsche Telekom Kundenportal. بمجرد حل هذا ، سأطالب باستعادة بعض المال.
أضفت رابطًا لهذه المقالة: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.html

bmarwell هل سمعت منهم من قبل؟ فعلت الشيء نفسه مع "Stoerungsmeldung" لكن ذلك كان كارثة كاملة. لقد أرادوا إرسال فني إلى منزلي و / أو DSLAM "لإصلاح هذا" وعندما اتصلت مرة أخرى لإلغاء ذلك ، كان الخط الساخن جاهلاً تمامًا عندما أخبرت عن مشكلات في العمود الفقري والتي لا يمكن التحايل عليها إلا لعدم استخدام توجيه Telekom القياسي (على سبيل المثال عبر VPN) ، ثم أرادت أن تبيعني خدمة "Computerhilfe".

أرادت شركة Deutsche Telekom تقديم حل بحلول الأسبوع الماضي. 🙄 أود أن أقول ، من الأفضل أن تطلب من فريق Twitter معاودة الاتصال بك. إنهم يعرفون المزيد عما يحدث. لقد أخبرت الداعم أيضًا بتعليم فريق المستوى الأول حول هذه المشكلة. لم يحدث كما يبدو.

لذا ، قم بإزعاج فريق Twitter. أعتقد أنه @ telekom_hilft أو ما شابه.

عملت معي مع NordVPN. مزود دويتشه تليكوم Sucks مع أمازون

التنزيل باستخدام lftp باستخدام عدة اتصالات متزامنة يساعد في تخفيف الألم قليلاً. على سبيل المثال

lftp -c "pget -c -n 20 https://github.com/mikefarah/yq/releases/download/3.4.1/yq_linux_amd64"

ومع ذلك ، فإن أوقات التنزيل لا تزال بعيدة عن المعتاد.

الحل الخاص بك رائع ، لقد نجح.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

ChristianCiach picture ChristianCiach  ·  7تعليقات

sxa picture sxa  ·  6تعليقات

a-roberts picture a-roberts  ·  6تعليقات

sophia-guo picture sophia-guo  ·  6تعليقات

agilob picture agilob  ·  6تعليقات