السلام عليكم ورحمة الله وبركاته.
أعمل على معالجين منفصلين تمامًا في النظام، سيتواصلون فيما بينهم، أحاول البعد عن الحلول الخاصة بـUnix لأنه سيعمل أيضًا على ويندوز، وسيكون Windows Native لن أستخدم أي Hacks، الآن أمامي بعض الحلول، الترتيب بحسب الأصعب:
Shared Memory: الحل الأصعب يوجد الكثير من الإختلافات بين Unix وويندوز، وأي خطأ بسيط سيؤدي إلى فشل المعالجين، لكني أرى أنه الأسرع ذاكرة واحدة لا داعي لكتابة نفس البيانات في ذاكرة كل برنامج، ولن أحتاج إلى عملية معالجة كبيرة لتفسير البيانات.
stdin/stdout/stderr: عندما نتحدث عن تواصل بين معالجين سنجد أن هذا الحل هو الأكثر شيوعًا، والأفضل في تحكم أحد المعالجين في الأخر، لكن ماذا عن البطء فيه.
TCP Socket: الحل الأكثر سلاسة وسهولة وعبورًا للمنصات، لكن يبدو أني سأضحي بالسرعة والذاكرة، على حساب استخدامه.
أي من الحلول ترى سيكون مناسبًا؟ وهل ترى حلًا أخر؟
التعليقات
ليس لدي خبرة بهذا النوع من البرمجة ، و لكن هناك ايضاً Message Queue ، يمكنك استعمال احد الحلول المجانية و المفتوحة المصدر كـ RabitMQ و ZeroMQ و سيكون مشابه للطريقة الثالثة.
ننتظر ان يأتي شخص له خبرة بهذا المجال.
صديقي لا أتحدث عن المكتبة أو التطبيق أتحدث عن الطريقة فقط، وإن كنتُ سأستخدم Network Socket سأستخدمها من النظام مباشرًا بدون أي Wrapper أو أي مكتبة تعطل العمل، أحتاج إلى سرعة عالية جدًا في البرنامج، واستخدام مكتبة خارجية سيجعل العمل بطيئًا.
هل قمت بأي قياسات تؤكد كلامك؟ ZeroMQ سيستخدم lockless message queue و shared memory في حالة أن طرفي الاتصال يعملان تحت نفس نظام التشغيل. لن تحصل على سرعة أفضل من هذه.
ثانيا: هل تبينت أن فعلا لديك مشكلة في السرعة؟ في الغالب الحسابات أو الإدخال أو الإخراج هو من يعطل العملية وتوفير أجزاء ضئيلة من الثانية في الاتصال ليس له أي فائدة مطلقا.
ثالثا:تكلفة ال abstraction في المكتبات في الغالبية العظمى من الحالات تتضائل أمام الوقت التي تحتاجه لل-context switch ومعالجة ال IO في النواة.
في حالة أن الأمر لا يتطلب تدخل النواة أشك في أنك ستقوم بكتابة كود أفضل من المكتبات المتاحة.
هل قمت بأي قياسات تؤكد كلامك؟ ZeroMQ سيستخدم lockless message queue و shared memory في حالة أن طرفي الاتصال يعملان تحت نفس نظام التشغيل. لن تحصل على سرعة أفضل من هذه.
لم أكن أعرف هذا كنت أظنه يستخدم فقط Socket عادي جدًا ذا من رد @horizon ، سأجربه وأعود إليك، الجميل أني وجدتُ ملفات البناء لـMingw.
المشكلة الأخرى أنه سيعمل أيضًا على Linux/ARM معالج ذو ARMV6 32Bit لذا أداة المعالج ضعيف وأحتاج أسرع طريقة، وأقل حجم للملف التنفيذي ذاكرة الحاسوب الصغير قليلة جدًا، وأيضًا الذاكرة العشوائية.
جربتُ Glib Socket ولم يكن سريعًا في ويندوز بل نفس الخادوم بـWindows API كان أسرع، لا أعرف عن ZeroMQ.
لا أعرف ما تقصد، لكن خادم Glib كان يحتاج إلى متوسط بين 50-200ms لبدء الـSocket على معالج AMD Althon قديم ما سيعمل عليه البرنامج، والبرنامج بنيته على مجمع MinGW-64 ذي إصدار 4.4.7 GCC تقريبًا، لا أعرف لما كان التأخر في عملية البدء مقارنة بـ20-15ms على نفس المعالج على نظام Linux بـGlib ونفس المتوسط تقريبًا للخادوم بـWindows API، لم أهتم يومًا بالسرعة بهاته الطريقة البرنامج أكتبه للتسلي والتجربة، فقط، وأريد به زيادة خبرتي في التعامل مع النظام، ليس عملًا حقيقًا.
ماذا تعني ببدء ال socket؟ g_socket_service_new؟ g_socket_service_start؟
لو كل همك الاتصال بين برنامجين لم تعبء بسرعة شيء ستفعله مرة وحيدة في الجلسة؟
g_socket_service_start وتأخر بسيط في incoming signal، في الحقيقة ليس مرة واحدة على الطرف الآخر معالج مع مفسر Lua يُفتح عدّة مرات لإضافات مختلفة، مع كل إضافة يفتحها المستخدم، لم أستخدم برنامج واحدة مع Threads لسبب ما أجهله :) مجرد رغبة في فصل كل معالج على حدى، ممم كل هدفي في المشروع كما أخبرتك تقوية خبرتي، شكرًا لك على العموم سأستخدم ZeroMQ وإن تسمح سأريك العمل لتطلع عليه إن إنتهيتُ منه.
لكني لم اذكر انه يستخدم socket -_-
أيا يكن ، كنت اعرف ان ZeroMQ قد يكون افضل في حالتك لأنه يعتبر الاسرع و لكن يفتقر الى بعض الميزات.
و لكن لم اعرف انه يستطيع استخدام Shared Memory.
اقترحتهم لأني قرأت ان احدى الطرق لعمل interop بين سي شارب و جافا هي بإستعمال Message Queue.
@horizon @a3f شكرًا لكما، سأستخدم ZeroMQ
قرأتُ هذا http://zguide.zeromq.org/pa... وبعد قليل من التجارب يبدو أنني وجدتُ الحل الذي أريد شكرًا لكما مجددًا.