Здравствуйте, kochetkov.vladimir, Вы писали:
k> P>> f>> Он постоянно держит соединение открытым?
k> P>> S>Да.
k> P>> И это неверно. В корне.
k> S>Тоесть по твоему очень большое количество софта в корне неверно работает? Пояснишь?
k> Легко. Вот скажи, как ты думаешь, почему люди не сидят на толчке постоянно, а ходят туда только тогда, когда им приспичит?
Да ладно вам, можно подумать, софта с постоянными коннектами мало. Тот же comet не от хорошей жизни применяется, верно? Касаемо ведги/кальпы, она находится примерно там же, где и решения с терминалами. Чуть полегче, но в целом тот же геморой.
Здравствуйте, hattab, Вы писали:
H>Шо, и ремоут десктопа/клиента нет? VNC? FTP? BitTorrent? ICQ? и др. Неверю
Ну приврал немножко. FTP — я видал в гробу, где ему и место. BitTorrent-у достаточно UDP вообще-то.
VNC/ремоут/ICQ/мессенджер — это как раз те приложения/сервисы, которые имеют хорошие бонусы от постоянного соединения, и попытайся их реализовать по другому — думаю результат был бы похуже. Вот только контекст пользователя тут вообще не причём.
Здравствуйте, fddima, Вы писали:
f> H>Шо, и ремоут десктопа/клиента нет? VNC? FTP? BitTorrent? ICQ? и др. Неверю
f> Ну приврал немножко. FTP — я видал в гробу, где ему и место.
Ну, я например HTML-мордие в гробу видал, так что же мне не признавать наличия HTML-мордовых приложений
f>BitTorrent-у достаточно UDP вообще-то.
Пиры соединяются по TCP. UDP Там для DHT, если мне память не изменяет.
f> VNC/ремоут/ICQ/мессенджер — это как раз те приложения/сервисы, которые имеют хорошие бонусы от постоянного соединения, и попытайся их реализовать по другому — думаю результат был бы похуже. Вот только контекст пользователя тут вообще не причём.
Как это контекст не причем? Ты же не думаешь, что всякие там ремоуты отсылают на клиента полные снимки экранов, а всякие там IM'ы не используют непосредственно коннект для идентификации юзера.
S>>Тоесть по твоему очень большое количество софта в корне неверно работает? Пояснишь? F> Я пожалуй не совру, но такого софта заинсталленого на моей машине просто нет. F> Statefull-сервисы могут эффективны в достаточно специфичных условиях. Нужно понимать условия. Мой последний проект использует — stateless сервер приложений. Да, кстати, сессий там тоже нет. Т.е. нет вообще. Хотя, row-based security — есть. Магия да и только...
Не грузи человека. Он даже близко не представляет, что такое stateless и row-based security. Лучше согласись сразу, что «эта ниправильна патамушта»
Здравствуйте, Mamut, Вы писали:
M>Не грузи человека. Он даже близко не представляет, что такое stateless и row-based security. Лучше согласись сразу, что «эта ниправильна патамушта»
Здравствуйте, hattab, Вы писали:
f>> Ну приврал немножко. FTP — я видал в гробу, где ему и место. H>Ну, я например HTML-мордие в гробу видал, так что же мне не признавать наличия HTML-мордовых приложений
FTP как-то не особо удачным вышел.
f>>BitTorrent-у достаточно UDP вообще-то. H>Пиры соединяются по TCP. UDP Там для DHT, если мне память не изменяет.
Вроде бы достаточно uTP, хотя могу ошибаться. Разумеется как и в любых P2P — всё зависит от клиентов.
f>> VNC/ремоут/ICQ/мессенджер — это как раз те приложения/сервисы, которые имеют хорошие бонусы от постоянного соединения, и попытайся их реализовать по другому — думаю результат был бы похуже. Вот только контекст пользователя тут вообще не причём. H>Как это контекст не причем? Ты же не думаешь, что всякие там ремоуты отсылают на клиента полные снимки экранов, а всякие там IM'ы не используют непосредственно коннект для идентификации юзера.
VNC фактически посылает полные снимки экрана (хоть и с оптимизациями), и кстати это реально нормально работает, скажем по сравнению с XDMCP.
И я не спорил, что постоянное соединение в конкретных случаях может давать свои плюсы, я об этом и говорю. Но и минусов отгрести можно. И вообще это всё к тому, что необходимость и способ получения контекста юзера не является основопологающим фактором в вопросе выбора архитектуры.
Здравствуйте, fddima, Вы писали:
f> f>> Ну приврал немножко. FTP — я видал в гробу, где ему и место.
f> H>Ну, я например HTML-мордие в гробу видал, так что же мне не признавать наличия HTML-мордовых приложений
f> FTP как-то не особо удачным вышел.
Согласен, мне тоже не нравится
f> f>>BitTorrent-у достаточно UDP вообще-то.
f> H>Пиры соединяются по TCP. UDP Там для DHT, если мне память не изменяет.
f> Вроде бы достаточно uTP, хотя могу ошибаться. Разумеется как и в любых P2P — всё зависит от клиентов.
На счет клиентов согласен (тем более, что "мю" нам как бэ намекаэ ). Моя aria2 тянет по TCP.
f> f>> VNC/ремоут/ICQ/мессенджер — это как раз те приложения/сервисы, которые имеют хорошие бонусы от постоянного соединения, и попытайся их реализовать по другому — думаю результат был бы похуже. Вот только контекст пользователя тут вообще не причём.
f> H>Как это контекст не причем? Ты же не думаешь, что всякие там ремоуты отсылают на клиента полные снимки экранов, а всякие там IM'ы не используют непосредственно коннект для идентификации юзера.
f> VNC фактически посылает полные снимки экрана (хоть и с оптимизациями), и кстати это реально нормально работает, скажем по сравнению с XDMCP.
Тут говорится о другом Если он определяет изменившиеся пиксели, значит контекст так или иначе присутствует.
f> И я не спорил, что постоянное соединение в конкретных случаях может давать свои плюсы, я об этом и говорю. Но и минусов отгрести можно. И вообще это всё к тому, что необходимость и способ получения контекста юзера не является основопологающим фактором в вопросе выбора архитектуры.
Здравствуйте, hattab, Вы писали:
f>> Вроде бы достаточно uTP, хотя могу ошибаться. Разумеется как и в любых P2P — всё зависит от клиентов. H>На счет клиентов согласен (тем более, что "мю" нам как бэ намекаэ ). Моя aria2 тянет по TCP.
Да, и правда. Сразу видно кто юзает мю. В KTorrent ещё есть, кстати.
f>> VNC фактически посылает полные снимки экрана (хоть и с оптимизациями), и кстати это реально нормально работает, скажем по сравнению с XDMCP. H>Тут говорится о другом Если он определяет изменившиеся пиксели, значит контекст так или иначе присутствует.
Я подразумевал это под оптимизациями. Насчёт контекста — всё ещё проще — он уже есть начиная с frame buffer на серверной стороне. В сессии (соединении), конечно тоже есть.