هل الاقتراع الطويل ممكن في محرك تطبيق Google؟

Question

أحتاج إلى تقديم تطبيق يحتاج إلى استطلاع الخادم في كثير من الأحيان ، ولكن GAE لديها قيود على الطلبات ، وبالتالي فإن تقديم الكثير من الطلبات قد يكون مكلفًا للغاية. هل من الممكن استخدام الاقتراع الطويل وتقديم الطلبات الانتظار حتى ماكسيوم 30 ثانية للتغييرات؟

Answer 1

لدى Google Appengine واجهة برمجة تطبيقات قناة ميزة جديدة ، مع وجودك إمكانية بناء تطبيق حقيقي في الوقت الفعلي.

حل آخر هو استخدام خادم المذنب من الجزء الثالث مثل mochiweb أو ملتوية بنمط iframe.

Client1 ، في انتظار الحدث:

client1 --Iframe Pattern--> Erlang/Mochiweb(HttpLongPolling):

Client2 ، إرسال رسالة:

client2 --XhrIo--> AppEngine --UrlFetch--> Erlang/Mochiweb

لاستخدام Mochiweb مع نمط المذنب ، كتب ريتشارد جونز موضوعًا جيدًا (على Google: Richard Jones A Million-User Comet Application).

Answer 2

لقد حاولنا تنفيذ حل شبيه بالذوبان الطويل على محرك التطبيق ، مع نتائج مختلطة.

def wait_for_update(request, blob):
    """
    Wait for blob update, if wait option specified in query string.
    Otherwise, return 304 Not Modified.
    """
    wait = request.GET.get('wait', '')
    if not wait.isdigit():
        return blob
    start = time.time()
    deadline = start + int(wait)
    original_sha1 = blob.sha1
    try:
        while time.time() < deadline:
            # Sleep one or two seconds.
            elapsed = time.time() - start
            time.sleep(1 if elapsed < 7 else 2)
            # Try to read updated blob from memcache.
            logging.info("Checking memcache for blob update after %.1fs",
                         elapsed)
            blob = Blob.cache_get_by_key_name(request.key_name)
            # Detect changes.
            if blob is None or blob.sha1 != original_sha1:
                break
    except DeadlineExceededError:
        logging.info("Caught DeadlineExceededError after %.1fs",
                     time.time() - start)
    return blob

المشكلة التي أراها هي أن الطلبات التي تتبع طلبًا طويلًا ، يتم تسلسلها (متزامن) وراء طلب الاستمرار طويل. أستطيع أن أنظر إلى أثر في الكروم ورؤية جدول زمني مثل هذا:

1. طلب 1 أرسل. احصل على (غير مُعدِّل).
2. طلب 2 أرسل. تعديل النقطة.
3. بعد وقت كامل خارج ، طلب 1 إرجاع (البيانات غير المعدلة).
4. تتم معالجة الطلب 2 على الخادم ، ويعيد النجاح.

لقد استخدمت Wireshark و Chrome/Timeline لتأكيد أنني أرسل طلب التعديل إلى الخادم على اتصال TCP متميز من الاتصال الطويل. لذلك يجب أن يكون هذا snychronization سعيدًا على خادم إنتاج محرك التطبيق. لا توثق Google هذه التفاصيل عن سلوك الخادم ، على حد علمي.

أعتقد أن انتظار API للقناة هو أفضل أمل في الحصول على سلوك جيد في الوقت الفعلي من محرك التطبيق.

Answer 3

لا أعتقد أن الاقتراع الطويل ممكن. مهلة الطلب الافتراضي لـ Google Appengine هي 30 ثانية. في الاقتراع الطويل إذا استغرقت الرسالة أكثر من 30 ثانية لتوليدها ، فسوف تفشل. ربما تكون أفضل حالًا باستخدام الاقتراع القصير.

نهج آخر هو "محاكاة" الاقتراع الطويل مع الحد الأقصى 30 ثانية. للقيام بذلك إذا لم تصل رسالة إلى الداخل ، على سبيل المثال ، يمكن للخادم إرسال رسالة "رمزية" بدلاً من رسالة عادية ، مما يتطلب من العميل استهلاكها والاتصال مرة أخرى.

يبدو انه هناك طلب المواصفات (ومقبول) على Google Appengine للاقتراع الطويل