можно почитать нафига на этапе клиент -> драйвер клиенту надо держать кучу открытых портов?
Я как-то привык к пулл схеме, а тут выходит пуш с сервера в клиент?
очевидно, в ситуациях, когда заранее неизвестно с какого IP придет ответ, нужен слушающий сокет.
Дык а нафига клиенту то слушать?
потому что он не знает куда подключаться. неизвестна топология. и еще, если работа выполняется с восстановлением сбоев, невозможно предположить какой в конечном итоге узел выдаст результат. Может вообще вновь созданный узел. (это просто рассуждения из всем известных вещей. читать спецификацию протокола я, конечно, не буду)
Ну как я представляю обычно подобную архитектуру. У нас есть клиент, он идет на сервер, делает там чот, отрубается, потом когда еще надо сходить, заходит снова на тот же сервер и делает еще чот. А тут у клиента выходит надо иметь открытый порт шоб драйвер пришел и в него положил результат? Што? Причем не один а целый рэнж?
ну это же не просто сервер, а набор серверов и важно не гонять данные через промежуточные или центральные точки. придумать могли что угодно.
в фтп работало же)
Драйвер как я понимаю один
Там разве на клиенте надо входящий порт открыть? Не в курсе честно говоря
ftp active mode
Если очень много клиентов постоянно держат открытый коннект к серверу - он и сдохнуть может. Начиная с какого-то масштаба дешевле асинхронщина
Не, я это понимаю. Я не понимаю нафига в обратную сторону подключения
Обсуждают сегодня