Что произойдет с именованным каналом, если сервер выйдет из строя?

я мало знаю о каналах, но использовал один для соединения двух процессов в моем коде на визуальном C++. Канал работает хорошо, но мне нужно добавить к нему обработку ошибок, поэтому я хотел знать, что произойдет с каналом, если создавший его сервер выйдет из строя, и как мне распознать его из клиентского процесса?

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

Редактировать: Как повлияет на память, если я продолжу создавать новые каналы (скажем, используя системное время в качестве имени канала), в то время как предыдущий был сломан из-за сбоя сервера? Будут ли удалены из памяти эти сломанные трубы?


windows c++ named-pipes
person Sneha    schedule 10.10.2010    source источник
comment
Обратите внимание, что лучший способ добавить обработку ошибок — изучить документацию всех функций, которые вы вызываете, чтобы увидеть все их возможные ответы на ошибки. Обработайте их все, возможно, принимая во внимание условия, вызывающие эту ошибку. Что вы делаете, так это думаете о конкретном состоянии ошибки и выясняете, какую реакцию на ошибку оно вызывает. Если вы не очень изобретательны, результатом этого будет то, что некоторые ошибки останутся необработанными в вашем коде.   -  person Steve Jessop    schedule 10.10.2010
comment
Привет, мне сказали подумать о сбое сервера, и я не знаю, что происходит с каналами в таком случае, вы можете помочь?   -  person Sneha    schedule 10.10.2010
comment
Я пытаюсь понять, что вы подразумеваете под сбоем сервера. Вы имеете в виду, если умирает сам сервер или вы имеете в виду, если ваше приложение падает?   -  person NotMe    schedule 11.10.2010
comment
У меня есть приложение с двумя процессами, один из которых я рассматриваю как сервер. Даже когда этот процесс умирает, другой может продолжаться, по крайней мере, для нескольких других функций, которые может выполнять это мое приложение.   -  person Sneha    schedule 11.10.2010

Ответы (2)


arrow_upward
1
arrow_downward

IIRC функция ReadFile или WriteFile вернет FALSE, а GetLastError() вернет STATUS_PIPE_DISCONNECTED

Я думаю, что такая обработка реализована в вашем коде, если нет, вам лучше добавить ее ;-)

person Vinzenz    schedule 10.10.2010
comment
А что будет с пробитой трубой? Будет ли он удален из памяти, если я повторно использую тот же именованный канал? - person Sneha; 10.10.2010
comment
Вы закрываете свой дескриптор канала (клиентский дескриптор), а затем пытаетесь повторно подключиться. Затем он либо сообщит вам код ошибки Windows 2 (файл не найден), либо, если сервер запущен, он сможет повторно подключиться. - person Vinzenz; 10.10.2010
comment
Как повлияет на память, если я продолжу создавать новые каналы, в то время как предыдущий был сломан из-за сбоя сервера? - person Sneha; 11.10.2010
comment
Я не уверен, что именно вы подразумеваете под «воздействием памяти». Если вы не выделите память и забудете ее освободить, это не должно повлиять. Какого эффекта вы ожидаете? - person Vinzenz; 11.10.2010
comment
Я имею в виду, что если я продолжу создавать эти каналы, и эти каналы останутся в памяти, поскольку я их не закрываю, они сломаны из-за сбоя сервера, это приведет к большому количеству утечек памяти, что затруднит выполнение других функций, которые не зависят от этого. часть? - person Sneha; 11.10.2010
comment
Все ваши дескрипторы из сбойных приложений обычно закрываются операционной системой, то же самое и с несвободной памятью сбойного приложения. Вся память и все дескрипторы, которые не освобождаются приложением, освобождаются операционной системой после закрытия приложения. Есть несколько исключений, но эти ручки не среди них. - person Vinzenz; 11.10.2010
comment
В моем приложении есть два процесса, даже если мой серверный процесс дает сбой, другой процесс запущен и может продолжаться в течение нескольких операций без процесса, который я рассматриваю как сервер для канала, поэтому я беспокоился, не произойдет ли сбой приложения из-за эти открытые дескрипторы, может ли мой другой процесс столкнуться с проблемой, поскольку утечка памяти, вызванная сломанной трубой, будет большой. - person Sneha; 11.10.2010
comment
Что ж, вы всегда можете реализовать несколько принудительных тестовых сбоев в нескольких местах и ​​посмотреть, соответствует ли поведение ожидаемому. Только то, что вы можете быть в безопасности. Никогда не помешает проверить такие вещи самостоятельно, сумма, которую вы узнаете из этого, огромна, поверьте мне :-) - person Vinzenz; 11.10.2010
comment
Я бы с удовольствием это сделал, но крайний срок подачи этой заявки очень близок, и поэтому я надеялся найти несколько быстрых ответов! В любом случае спасибо. - person Sneha; 11.10.2010
comment
@Sneha: должно пройти менее 30 минут, чтобы запустить два приложения, посмотреть, как передаются некоторые данные, и убить серверное приложение с помощью диспетчера задач, чтобы посмотреть, что произойдет. - person NotMe; 11.10.2010

arrow_upward
1
arrow_downward

Я просто хочу выбросить это туда.

Если вам нужен надежный метод передачи данных между двумя приложениями, вы можете рассмотреть возможность использования MSMQ или даже внедрения BizTalk или другой платформы сообщений.

Есть несколько вещей, которые следует учитывать:

  1. что произойдет, если сервер перезагрузится или потеряет питание?
  2. Что произойдет, если серверное приложение перестанет отвечать?
  3. Что произойдет, если серверное приложение будет убито или полностью исчезнет?
  4. Каков правильный ответ клиентского приложения в каждом из вышеперечисленных случаев?

Каждый из этих контекстов представляет потенциальную потерю данных. Если потеря данных неприемлема, то именованные каналы — это не тот механизм, который вам следует использовать. Вместо этого вам нужно как-то сохранять сообщения.

MSMQ, сохранение в базе данных или даже использование Biztalk могут обеспечить живучесть самого сообщения.

Если происходит 1 или 3, то именованный канал исчезает и должен быть воссоздан новым экземпляром вашего серверного приложения. Если произойдет № 2, то канал не исчезнет, ​​пока кто-то либо не перезагрузит сервер, либо не убьет серверное приложение и не запустит его снова.

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

Не зная природы используемых данных и коммуникационных процессов, трудно рекомендовать правильный подход.

person NotMe    schedule 11.10.2010
comment
Вы уверены, что MailSlots постоянны? Может быть, вы имеете в виду MQ, как MSMQ, а не MailSlot? - person user1121956; 03.12.2012
comment
@ user1121956: Вау, ты прав. Я имел в виду MSMQ, а не почтовые слоты. Почтовый слот закрывается, а непрочитанные сообщения удаляются, когда закрывается процесс-владелец. Так что это определенно не было бы хорошей идеей. - person NotMe; 03.12.2012