О сокетах и не только -------- for grigori

[Макс]

WAS71
в своем сообщении я пропустил одно слово "не будут 200 дочек одновременно висеть на сокетах"
допустим девайс делает ХТТП-запрос на imei.php - там создается listen-socket который начинает обрабатывать входящие соединения.
Допустим в этот момент поступает еще один запрос от второго девайса на imei.php - у тебя не пройдет создание listen-сокета, во втором процессе не сработает socket_bind() потому что другой процесс уже слушает этот адрес:порт.

Насчет последовательной обработки:
допустим у тебя 200-запросов в секунду, socket_select() в этот момент вернет тебе 100-200 элементов в массиве $read и потом ПХП-процесс последовательно будет в цикле делать socket_read() а затем работу с базой. За секунду скорее всего PHP-процесс не успеет обработать все это.

ЗЫ
вообще схема с listen-сокет в веб-скрипте неправильная. Но для меня это настолько очевидно, что я затрудняюсь внятно аргументировать это

 

[WAS71]

а еще неплохо было бы рассказать, какая работа проделывается сервером в самых тяжелых случаях

что имеется ввиду ?

 

[grigori]

WAS71
первый телефон соединился и занял первую дочку апача, которая открыла для него порт
второй авторизовался на другой дочке апача - как 1я дальше узнает, что надо разрешить 2му телефону соединение на порт?

Макс
открывать разные порты

-~{}~ 03.06.09 10:44:

- что имеется ввиду ?
это когда все 200 устройств одновременно соединяются

 

[Wicked]

а еще неплохо было бы рассказать, какая работа проделывается сервером в самых тяжелых случаях

что имеется ввиду ?

что в среднем требуется от сервера делать за одну итерацию (раз в секунду) общения с мобильным устройством? может ли объем вычислений (вычислений - в разных смыслах) увеличиваться при каких-нибудь условиях? будут ли среди таких вычислений довольно сложные, из разряда общения с внешними сервисами, с базой данных, с диском, ... ?

-~{}~ 03.06.09 18:38:

знание этого очень важно для принятия решения, писать ли свой сокетный демон или лучше обойтись стандартной моделью работы php

-~{}~ 03.06.09 18:38:

вообще схема с listen-сокет в веб-скрипте неправильная. Но для меня это настолько очевидно, что я затрудняюсь внятно аргументировать это

золотые слова

-~{}~ 03.06.09 18:41:

grigori

открывать разные порты

может проще сделать так, чтобы демон (если будет решено использовать демон) был один, был всегда запущен (а не по запросу), и принимал imei при хэндшейке, авторизуя или не авторизуя соединение мобильного устройства?

 

[ys]

А не проще ли в inetd прописать в качестве сервера php скрипт, который не будет танцевать с бубном вокруг сокетов, а читает из стандартного stdin и пишет в стандартный stdout?

По поводу общения с http частью есть масса вариантов, начиная с фалов, заканчивая базой или memcache.

 

[Wicked]

inetd

ого... какая интересная штуковина

 

[WAS71]

По поводу общения с http частью есть масса вариантов, начиная с фалов, заканчивая базой или memcache.

фтп c файлами прошел, http прошел, memcache - незнаю о чем это, и судя по названию не пойдет

БД самое то..


inetd - тоже кстати незнаю

 

[ys]

> inetd - тоже кстати незнаю


man inetd
man inetd.conf

Покажи серверу, что ты man. (c) bash.

 

[Ирокез]

эээ
свои 5-ть копеек )
а может перевести сокет в неблокирующий режим

socket_set_nonblock

 

[WAS71]

Wicked

Про постоянные http-соединения я уже писал.

где можно почитать о том что писал, не хотят мои сокеты жить вечно - вешаются через несколько суток

 

[Wicked]

экстремист

вешаются - переоткрывай.

 

[WAS71]

прошу помощь зала ))

легко сказать, знал бы как контролировать что сокет завис - может бы и сделал - когда подключаюсь телнетом - это выглядит как пустые ответы от сервера на посылки данных , в рабочем состоянии ответ не пустой - а в зависит от результата выполнения
посылка DATA[пакет данных 32-512 байт] - ответ - типа ОК - Error

 

[ys]

SO_KEEPALIVE

 

[WAS71]

и куда это

SO_KEEPALIVE

-~{}~ 09.06.09 15:32:

вообще кто то реально работал с сокетами, или у всех только теория

 

[ys]

>и куда это

Обычно, если нет понятия куда, втыкают это в гугл.
... и изучают результаты.