websockets მართლაც დიდი ნაბიჯია მომავალი web-ისთვის, საკმაოდ ბევრ რამეს გაამარტივებს და უფრო სასიამოვნოს და სწრაფს გახდის საიტებს. რაც შეეხება სერვერთან გახსნილი კავშირის პრობლემას, აქაც ღია არის სულ კავშირი სერვერი თავისი ინიციატივით ვერ დაუკავშირდება ბრაუზერს. უბრალოდ შენ არ გჭირდება იმპლემენტაცია გაუკეთო მაგ კავშირის “მომსახურე” thread (რომელიც შენ აპლიკაციაში არის და არა ვებსერვერის thread). მომსახურებაში ვგულისხმობ დაახლოებით იგივეს რაც ეხლა ხდება polling-ის დროს javascript-ის მხარეს (რაღაც პერიოდულობით ამოწმებ ხო არ არის რაიმე შეტყობინება სერვერზე), ანუ იგივე უნდა გაგეკეთებინა აქამდე სერვერის მხარესაც long polling-ის დროს, რაღაც პერიოდულობით უნდა “დააძინო” request-ის მომსახურე thread, გაღვიძების მერე შეამოწმო გაქვს თუ არა მესიჯები, გააგზავნო და ისევ დაიძინო. websocket-ების გამოყენებით კი ამდენი წვალება არ არის საჭირო. მარტივი მაგალითი შეგიძლია ნახო აქ: http://bret.appspot.com/entry/web-sockets-in-tornado
პ.ს. საინტერესო ვიდეო ჩანს, ვნახავ აუცილებლად დაძინებამდე 😀 😛
@ლეკვა
🙂 ეგეთ რამეებს თუ დაამატებენ კიდევ, კარგი იქნება.. თორემ ახლანდელი საიტები სულ სხვანაირია, და აჯაქსი რომ აჯაქსია და მინიმუმ ყოველ მეორეში გამოიყენება, თავიდან ბოლომდე ჰაკია.. ნუ ეგ ზოგადად ვამბობ 😀 შენ ჩემზე მეტი იცი მაგ სფეროში
@Quick
😀 დავგუგლე და მართალი ხარ. მაგრამ ძალიან გავრცელებული თუა, ესე იგი ახალი სიტყვაა და შეცდომა აღარაა 😀
Polling მეთოდის გამოყენებაზე ვმუშაობ ერთ წელიწადზე მეტია და ჩვეულებრივ სერვერის დატვირთვზე ასე ვთქვათ კატასტროფულ ოპტიმიზაციას მივაღწიე ჩევულებრივი 2 GB ოპერატიულით აღჭურვილი სერვერი ერთდროულად 5000 კაცს გაუძლებს მალე ექსპერიმენტულ პროექტს გავუშვებ სადღაც მარტის ბოლოს. ისე მოხალისეებს ვეძებ ვინც კონკრეტულ მოდულებზე იმუშავებს და ოპტიმიზაციას გაუკეთებს
კარგი სტატიაა, საჭირო ინფორმაცია წერია 😛
websockets მართლაც დიდი ნაბიჯია მომავალი web-ისთვის, საკმაოდ ბევრ რამეს გაამარტივებს და უფრო სასიამოვნოს და სწრაფს გახდის საიტებს. რაც შეეხება სერვერთან გახსნილი კავშირის პრობლემას, აქაც ღია არის სულ კავშირი სერვერი თავისი ინიციატივით ვერ დაუკავშირდება ბრაუზერს. უბრალოდ შენ არ გჭირდება იმპლემენტაცია გაუკეთო მაგ კავშირის “მომსახურე” thread (რომელიც შენ აპლიკაციაში არის და არა ვებსერვერის thread). მომსახურებაში ვგულისხმობ დაახლოებით იგივეს რაც ეხლა ხდება polling-ის დროს javascript-ის მხარეს (რაღაც პერიოდულობით ამოწმებ ხო არ არის რაიმე შეტყობინება სერვერზე), ანუ იგივე უნდა გაგეკეთებინა აქამდე სერვერის მხარესაც long polling-ის დროს, რაღაც პერიოდულობით უნდა “დააძინო” request-ის მომსახურე thread, გაღვიძების მერე შეამოწმო გაქვს თუ არა მესიჯები, გააგზავნო და ისევ დაიძინო. websocket-ების გამოყენებით კი ამდენი წვალება არ არის საჭირო. მარტივი მაგალითი შეგიძლია ნახო აქ: http://bret.appspot.com/entry/web-sockets-in-tornado
პ.ს. საინტერესო ვიდეო ჩანს, ვნახავ აუცილებლად დაძინებამდე 😀 😛
ვა ლილუ 🙂 რასაც მეკითხებოდი 3-4 დღის წინ და ვერ გიპასუხე თვითონ გაერკვიე, კარგია. მასე გააგრძელე, მე მჯერა შენი 🙂
პ.ს. ოღონდ სწორია “რეკომენდებული”, ეგ არა უშავს ძალინ გავრცელებული შეცდომაა 😉
@ლეკვა
🙂 ეგეთ რამეებს თუ დაამატებენ კიდევ, კარგი იქნება.. თორემ ახლანდელი საიტები სულ სხვანაირია, და აჯაქსი რომ აჯაქსია და მინიმუმ ყოველ მეორეში გამოიყენება, თავიდან ბოლომდე ჰაკია.. ნუ ეგ ზოგადად ვამბობ 😀 შენ ჩემზე მეტი იცი მაგ სფეროში
@Quick
😀 დავგუგლე და მართალი ხარ. მაგრამ ძალიან გავრცელებული თუა, ესე იგი ახალი სიტყვაა და შეცდომა აღარაა 😀
Polling მეთოდის გამოყენებაზე ვმუშაობ ერთ წელიწადზე მეტია და ჩვეულებრივ სერვერის დატვირთვზე ასე ვთქვათ კატასტროფულ ოპტიმიზაციას მივაღწიე ჩევულებრივი 2 GB ოპერატიულით აღჭურვილი სერვერი ერთდროულად 5000 კაცს გაუძლებს მალე ექსპერიმენტულ პროექტს გავუშვებ სადღაც მარტის ბოლოს. ისე მოხალისეებს ვეძებ ვინც კონკრეტულ მოდულებზე იმუშავებს და ოპტიმიზაციას გაუკეთებს