Polling და Pushing აჯაქსით

მივადექი საიტის შეტყობინებების (notifications) ნაწილს და ბლოგი ძალიან რომ არ მივივიწყო, ნანახის მიმოხილვას აქ გავაკეთებ 😀

შეტყობინებებში ვგულისხმობ მომხმარებელს რომ პატარა ღრუბელი გამოუჩნდება ხოლმე ”თქვენ მიიღეთ ახალი შეტყობინება”, ან ”თქვენს თემას აქვს ახალი გამოხმაურება”.. ან ჩატის ანალოგი ავიღოთ..  ეს არის შემთხვევა, როდესაც სერვერზე ხდება რაღაც მოვლენა და კლიენტს უნდა მიუვიდეს ამის შესახებ ინფორმაცია.

რადგან სერვერი ვერ იქნება ინიციატორი, აუცილებელია რომ პირველად მოთხოვნა კლიენტისგან გაიგზავნოს. პრობლემა კი იმაშია, რომ კლიენტმა წინასწარ არ იცის მოვლენა როდის მოხდება სერვერზე.

ამ ამოცანის გადასაჭრელად ძირითადად ორ გზას იყენებენ ხოლმე:

1. ყოველ 5 წამში (სიტყვაზე) ბრაუზერი ეკითხება სერვერს ჩემთვის რამე ახალი ხომ არ გაქვსო (უგზავნის მოთხოვნას XMLHttpRequest ობიექტის საშუალებით). სერვერიც თავის მხრივ პასუხს უბრუნებს და ასე გრძელდება დაუსრულებლად. ამას polling-ს ეძახიან.

2. ბრაუზერი მიმართავს სერვერს და ამის შემდეგ კავშირს არც ერთი მხარე არ ხურავს. HTTP ქონექშენი ღიაა. თუ სერვერზე რამე ახალი მოხდება, სტრიმის სახით გაუშვებს ინფორმაციას კლიენტთან ამ კავშირით. ეს push-ია.

ორივე მეთოდს თავისი დადებითი და უარყოფითი მხარეები აქვს და ამიტომ ერთი ხელის მოსმით ვერ იტყვი რომელია უკეთესი. განვიხილოთ.

polling-ს ზედვე ეტყობა როგორ ხარჯავს რესურს. ჯერ მარტო ამდენი ქონექშენის გახსნით და დახურვით სერვერს ტვირთავს, მით უმეტეს როცა მომხმარებლების რაოდენობა ძალიან დიდია. ბოლოს ვეღარ გაუძლებს იქით მხარეს სერვისი და მოკვდება 😀

მიუხედავად იმისა, რომ push-ს ეს პრობლემა არ აქვს, აქ სხვა სახით გვაქვს სერვერზე დატვირთვა. მას ძალიან დიდი რაოდენობით გახსნილი ქონექშენის ხელში ჭერა უწევს.

გადატვირთვის თავიდან ასაცილებლად IE 6/7 -ში შეზღუდვაც კია დაუხურავ კავშირებზე. ამ ბრაუზერში კლიენტს არ შეუძლია ქონდეს ორზე მეტი ღია ქონექშენი სერვერთან. ანუ მაგალითად, თუ ორ ტაბში გვაქვს გახსნილი ერთი და იგივე საიტი, რომელიც ასეთ დაუხურავ კავშირს იყენებს და მესამე ტაბშიც გავხსნით, მესამე აღარ ჩაიტვირთება.

ამისთვის ჰეკები არსებობს რა თქმა უნდა. სხვა მნიშვნელოვან ბრაუზერებს ამის პრობლემა არ ქონიათ.

გასათვალისწინებელია გახსნილი ქონექშენის სტრიმის გამაჩერებლებიც – ეს შეიძლება იყოს პროქსი სერვერები, სხვადასხვა firewall-ები ან ვებ სერვერი.. მაგალითად აპაჩის mod_jk კონექტორი (ტომკეტისთვის) ხელს უშლის თურმე push-ის რეალიზაციას.

იმ ბრაუზერებისთვის, რომლებსაც ნამდვილი push-ის გაკეთებაზე ბევრი პრობლემა აქვთ, არის კიდევ ერთი მეთოდი – long polling. აქ push-იც გვაქვს და poll-იც. ბრაუზერი გზავნის მოთხოვნას სერვერთან და თუ მეორე მხარეს მისთვის ჯერ არაფერი არ არის, სერვერი არ პასუხობს და ქონექშენს ღიას ტოვებს, ხოლო როცა რამე გამოჩნდება, ნაკადად კი არ უშვებს არამედ მთელ პასუხს უგზავნის უკან და ხურავს კიდეც. შემდეგ კლიენტი ისევ თავიდან გზავნის მოთხოვნას და ასე შემდეგ.

ძალიან აღარ ჩავუღრმავდები, მით უმეტეს რომ პრაქტიკულად ამის გაკეთება გადავიფიქრე და polling ვიკმარე, რომელიც ცუდი გადაწყვეტილება არ არის, თუ რეაქციის პატარა დრო არ არის აუცილებელი ამოცანისთვის და რამდენიმე წუთში ერთხელ განახლებაც საკმარისია.

თუმცა რა თქმა უნდა ამოცანას გააჩნია. Push , რომლის პატერნს Comet-საც ეძახიან გამოიყენება GMail-ში, GMail-ის ჩატში, GDocs-ში, Meebo-სა და სხვა ჩატის თუ collaborate რედაქტირების საიტებში.

პ.ს. long polling-ის თავიდან ასაცილებლად და სულ ღია კავშირების ხარჯზე ინფორმაციის მიმოცვლისთვის HTML 5-ის სპეციფიკაციაში შემოაქვთ WebSocket კლასი, რომლითაც ასეთი პატერნის რეალიზაციაა შესაძლებელი. http://dev.w3.org/html5/websockets/

პ.პ.ს. იმედია, ჩემი სიტყვებით გადმოცემული პოსტი დიდად არ დაშორდა რეალურ შინაარს 😀

რეკომენდირებული საყურებელი:

Interactive Websites with Comet and DWR  by Joe Walker

4 thoughts on “Polling და Pushing აჯაქსით

  • 01 თებერვალი, 2010 at 22:38
    Permalink

    კარგი სტატიაა, საჭირო ინფორმაცია წერია 😛

    websockets მართლაც დიდი ნაბიჯია მომავალი web-ისთვის, საკმაოდ ბევრ რამეს გაამარტივებს და უფრო სასიამოვნოს და სწრაფს გახდის საიტებს. რაც შეეხება სერვერთან გახსნილი კავშირის პრობლემას, აქაც ღია არის სულ კავშირი სერვერი თავისი ინიციატივით ვერ დაუკავშირდება ბრაუზერს. უბრალოდ შენ არ გჭირდება იმპლემენტაცია გაუკეთო მაგ კავშირის “მომსახურე” thread (რომელიც შენ აპლიკაციაში არის და არა ვებსერვერის thread). მომსახურებაში ვგულისხმობ დაახლოებით იგივეს რაც ეხლა ხდება polling-ის დროს javascript-ის მხარეს (რაღაც პერიოდულობით ამოწმებ ხო არ არის რაიმე შეტყობინება სერვერზე), ანუ იგივე უნდა გაგეკეთებინა აქამდე სერვერის მხარესაც long polling-ის დროს, რაღაც პერიოდულობით უნდა “დააძინო” request-ის მომსახურე thread, გაღვიძების მერე შეამოწმო გაქვს თუ არა მესიჯები, გააგზავნო და ისევ დაიძინო. websocket-ების გამოყენებით კი ამდენი წვალება არ არის საჭირო. მარტივი მაგალითი შეგიძლია ნახო აქ: http://bret.appspot.com/entry/web-sockets-in-tornado

    პ.ს. საინტერესო ვიდეო ჩანს, ვნახავ აუცილებლად დაძინებამდე 😀 😛

    Reply
  • 01 თებერვალი, 2010 at 23:31
    Permalink

    ვა ლილუ 🙂 რასაც მეკითხებოდი 3-4 დღის წინ და ვერ გიპასუხე თვითონ გაერკვიე, კარგია. მასე გააგრძელე, მე მჯერა შენი 🙂

    პ.ს. ოღონდ სწორია “რეკომენდებული”, ეგ არა უშავს ძალინ გავრცელებული შეცდომაა 😉

    Reply
  • 01 თებერვალი, 2010 at 23:45
    Permalink

    @ლეკვა
    🙂 ეგეთ რამეებს თუ დაამატებენ კიდევ, კარგი იქნება.. თორემ ახლანდელი საიტები სულ სხვანაირია, და აჯაქსი რომ აჯაქსია და მინიმუმ ყოველ მეორეში გამოიყენება, თავიდან ბოლომდე ჰაკია.. ნუ ეგ ზოგადად ვამბობ 😀 შენ ჩემზე მეტი იცი მაგ სფეროში

    @Quick
    😀 დავგუგლე და მართალი ხარ. მაგრამ ძალიან გავრცელებული თუა, ესე იგი ახალი სიტყვაა და შეცდომა აღარაა 😀

    Reply
  • 05 თებერვალი, 2010 at 14:04
    Permalink

    Polling მეთოდის გამოყენებაზე ვმუშაობ ერთ წელიწადზე მეტია და ჩვეულებრივ სერვერის დატვირთვზე ასე ვთქვათ კატასტროფულ ოპტიმიზაციას მივაღწიე ჩევულებრივი 2 GB ოპერატიულით აღჭურვილი სერვერი ერთდროულად 5000 კაცს გაუძლებს მალე ექსპერიმენტულ პროექტს გავუშვებ სადღაც მარტის ბოლოს. ისე მოხალისეებს ვეძებ ვინც კონკრეტულ მოდულებზე იმუშავებს და ოპტიმიზაციას გაუკეთებს

    Reply

კომენტარის დატოვება

თქვენი ელფოსტის მისამართი გამოქვეყნებული არ იყო. აუცილებელი ველები მონიშნულია *