| 0
- 26.09.2012 - 12:10
|
Delphi, Builder Собственно возник вопрос, а можно ли передать открытый сокет в другую программу? Это для того, чтоб делать "горячуюю" смену ПО на сервере. А то и так ошибок соединения хватает.     | | ||
| 1
- 26.09.2012 - 12:45
|
Технически, наверно, можно (если выносить в dll). ИМХО, уровень возможных косяков от этой схемы будет выше, чем польза. Что за приложение, которое нельзя вырубить на пару секунд? Навигатор ядрёной ракеты? :-) | | ||
| 2
- 26.09.2012 - 14:38
|
1-NTFS_ > Та ни. Просто прогнозируется частая смена сервака (ПО). Слишком всё сырое и много развития. А клиент глючит, при обрыве. Пока не вылечили (найти не можем, откуда у эксцепшена ноги растут, вроде бы всё обработали). | | ||
| 3
- 26.09.2012 - 16:06
| Цитата:
Но есть один важный момент. Я не могу сказать точно, будут ли прерваны уже установленные соединения (скорее всего нет, но вот с обработкой передаваемых данных точно могут быть проблемы). Но обработка новых подключений будет приостановлена точно. Это связано со спецификой метода "accept" библиотеки WinSock. Я думаю, что можно спокойно развернуть альфа-сервер, где уже отработать все необходимые моменты (В ТОМ ЧИСЛЕ ВОЗМОЖНОСТЬ ПЕРЕДАЧИ КЛИЕНТАМ ИНФОРМАЦИИ О ЗАВЕРШЕНИИ РАБОТЫ СЕРВЕРА В ТЕЧЕНИИИ N ВРЕМЕНИ. Я не знаю, кто у Вас занимается непосредственным проектирование, но ему медаль нужно дать, если второй раз не подумает о реализации данного момента), а затем разок устроить клиентам полный шутдаун (предварительно предупредив об этом). Если тестирование и доработку необходимо производить в режиме реального времени при работе с клиентами, то могу посоветовать Вам немного другую схему. Должен быть реализован полностью рабочий сервер, где методы обработки данных клиентов вынесены в отдельные библиотеки. В этом случае их можно будет заменять по мере необходимости. Через серверное приложение - сообщаем клиентским приложениям, что сервер не будет обрабатывать N-нные операции после их последнего завершения. Сервер их отработал, отключил использованную DLL, вы ее заменили, сообщили это серверному приложению об этом, а оно уже - клиентским. Обрывов в этом случае не будет. | | ||
| 4
- 26.09.2012 - 16:21
| Должен добавить одно замечание. Так как автор говорил о Delphi/Builder, то речь идет о Windows. Для Unix-систем, возможна передача дескриптора сокета другому процессу (sendmsg/recvmsg). | | ||
| 5
- 26.09.2012 - 16:44
|
4-Samael > Пасиб. Щаз попробуем обсудить вариант. Проблема, конечно, не критичная. Но как-то не интересно копаться в мелочах, когда есть более серьёзные проблемы. Остановить сервер на 5-10 мин, с оповещением, конечно можно. Однако, хотелось, конечно, этого не делать. Да и трабла там какая-то у клиента - вываливается, при обрыве. Щаз её копаем. Вроде все обработчики в курсе, что делать, если обрыв, ан нет - отваливается. Ну да ладно... Не такое разгрызали. | | ||
| 6
- 26.09.2012 - 16:54
|
Разве сокет не является чем-то вроде HANDLE? Если это так, то для них, как и всех хэндлов Винды , будет действовать правило - хендл имеет смысл только для процесса, где он создан. Поэтому ответ - НЕЛЬЗЯ. | | ||
| 7
- 26.09.2012 - 19:04
|
Лучше уж наладить клиента чтобы он от обрывов не падал. Это намного проще чем что то там мутить. Если использовать indy то там вроде это делается просто. to6 а про это читал http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx | | ||
| 8
- 26.09.2012 - 20:47
|
7-TVV1 > Мой друх, я не только про это читал, и даже (о ужас) юзал. Ты до конца читал? Там в списке возможных объектов есть сокет? Если уж на то пошло, то ты про это читал: WSADuplicateSocket? Но автору и это может не помочь, судя по докам. Надо пробовать. | | ||
| 9
- 26.09.2012 - 21:29
| to8 Ты это не передергивай в посте 6 ты писал про handel так что не надо ля-ля. | | ||
| 10
- 26.09.2012 - 22:52
| 9-TVV1 > ты не жужжи лишнего. Так можно передать сокет с помошью дубликатехандле или нет? | | ||
| 11
- 26.09.2012 - 22:53
| +10, уже совсем для демагогов - сокет передается прямо вызовом дубликатехандле, или все же сначала оным, а потом каким-нибуть способом IPC? :) | | ||
| 12
- 27.09.2012 - 00:02
|
Я думаю, что автор уже сделал выводы для себя, но все же добавлю. DuplicateHandle - тут явно не в тему: typedef PVOID HANDLE; typedef UINT_PTR SOCKET; WSADuplicateSocket - очень сомнительный метод для данной задачи, т.к. он может быть использован только дочерними процессами (или шагаем через внедреную либу). Кроме того, слышал о проблемах при активном QoS. | | ||
| 13
- 27.09.2012 - 13:53
|
12-Samael > Не "слышал", а об этом сказано в MSDN. :) Кстати, я так и не понял, каким образом помогло бы автору твое согласие с NTFS, в плане shared dll? | | ||
| 14
- 27.09.2012 - 22:56
| Цитата:
The WSADuplicateSocket function cannot be used on a QOS-enabled socket. Т.е. вообще не работает. Далее, можно увидеть репорт о правках, а на форумах третью информацию. В итоге однозначного ответа - нет, поэтому в моем ответе и была подобная "неопределенность". Цитата:
Но мне казалось, что я пояснил один момент. Для данной задачи нужно искать другие методы решения. Обновление ПО в режиме нон-стоп конечно выглядит красиво, но передача одного указателя соединения, не восстановит всю структуру данных, которую использовал первичный процесс. | | ||
| 15
- 28.09.2012 - 12:06
| 14-Samael > дааа, словоблудием ты умеешь страдать, чел.. | | ||
| 16
- 29.09.2012 - 00:42
|
Ладненько, не ругайтесь. Решили траблу. Научили клиента реконнектится при обрыве. Он, правда, пока, не сразу прочухивает, но потом начинает соображать, что надо бы. Ну, ничего, и это вылечим. | | ||
| 17
- 01.10.2012 - 11:21
| 16-Lucas > сделай Alive пакеты... Быстрее "прочухивать" станет :) | |
Интернет-форум Краснодарского края и Краснодара |
