Реализация соединения с сервером

[TanaTiX]

Описываю ситуацию:
Есть приложение (игра), которому для работы необходимо от сервера получать различные данные. Часть данных относительно стабильна (имя, фамилия, список игроков, очки и т.п.) и за время жизни приложения эти данные можно было бы получить несколькими запросами и без острой необходимости больше не обновлять; а часть желательно получать в режиме реального времени (собственно игра и чат в противовес блуждания по различным менюхам приложения).
Суть вопроса в том, в какой ситуации какие виды соединения (или одно) предпочтительней использовать (get/post, Socket, NetConnection)?

PS. почему спрашиваю - появились разногласия с серверным программистом в способе реализации. Свое мнение поэтому не излагаю.

Заранее спасибо.

[Psycho Tiger]

Socket - самый быстрый и гибкий. Я всегда за него.

[-De-]

А что, он набыдлокодил так, что сложно сменить с сокета на гет, а ты набыдлокодил так, что тебе тоже? =)
Делай как ему удобней, это его дело.

[TanaTiX]

-De-, еще никто ничего не кодил и тем более не быдлокодил
Я сделаю как считаю нужным, но создал тему не для набора постов, а потому что мнение интересно, желательно аргументированное.
Psycho Tiger, т.е. сокет всегда и во всем?

ЗЫ. забыл еще уточнить момент: приложение периодически должно спрашивать у сервера о том, вызывают ли пользователя на бой или нет. Как часто это должно происходить не скажу, пока не знаю.

[leofit]

Если уж пользователя вызывают на бой, то тогда сокеты.. Лучше всего наверное, при старте приложения дергать данные через (гет, пост, флешварсы), потом открывать сокет-сессию и держать канал. Тогда сокет-сервер будет сам дергать флешку клиента когда его вызывают на бой, выбрасывать сообщения чата и т.п., при необходимости можно предусмотреть команду смены имени, фамилии, очков и т.п. через тот же сокет... NetConnection может конечно все это осилить, но до тех пор пока игроков сравнительно немного (чел 500 мб одновременно), и более это прожорливо в плане ресурсов. Так что я за сокет

[Psycho Tiger]

Psycho Tiger, т.е. сокет всегда и во всем?

ну, если надо дёрнуть сервер один раз - например, чтобы сохранить результат игры - то обычный get/post. Если дёрнуть надо 2 раза - спросить, какие ресурсы доступны и сохранить - то уже лучше сокет.
Я просто давно уже не делаю что-то, где сокеты были не оправданы бы. NetConnection хорош только из-за RPC, но и на сокетах эта штуковина реализуется руками в 2 счета.

[TanaTiX]

Т.е. на основании вышесказанного и молчания других юзеров делаю вывод, что сначала get/post-запрос для получения вводных данных, а далее через сокетное соединение. Если будут еще мнения - с удовольствием выслушаю.

Добавлено через 1 минуту
leofit 500 человек, это про нагрузку на сервер или про чат? Чат планируется тет-а-тет.

[Psycho Tiger]

Это кстати глупость - "получить данные post`ом, остальное сокетом". Давайте данные получать сокетом, инфу post`ом, чат реализуем с NetConnection, а чтобы обновить картинку-аватарку в игре пользователю будет предоставлен фтп-доступ с просьбой залить туда картинку?

Если начали делать сокеты - делайте на них. Без всяких там постов. Пост в феврале будет.

[gloomyBrain]

Если начали делать сокеты - делайте на них. Без всяких там постов. Пост в феврале будет

Ну и в чем смысл? В моем понимании, если можно что-то сделать просто и быстро - надо это сделать просто и быстро. Зачем париться с созданием сокет-сервера, имеющего связь (нормальную, с буфером и тп) с БД, если на пыхе нужный скрипт пишется за 10 минут? Или зачем поднимать чат через long-polling, если для этого можно за 1 день написать сервер на JAVA?

Короче, я сторонник того, что сокеты нужны для моментальной реакции на изменнение данных, а http-запросы - для загрузки более или менее статического контента. NetConnection мне не нравится, потому что нужно долго и нудно читать как оно работает, чтобы сделать все по уму.

[TanaTiX]

gloomyBrain, с серверными технологиями знаком, скажем так, посредственно. Интересно как это будет все с учетом производительности. Т.е. если я потрачу день для явы (условно), то на сколько это будет эффективней непосредственно в работе?

Пост в феврале будет.

улыбнул=)