| Вопрос: Дисконнект сокетов в .Net | Добавлено: 21.04.06 00:31 |
Автор вопроса:  Neco | Web-сайт: neco.pisem.net | ICQ: 247906854 |
| Ответы | Всего ответов: 38 |
|
Номер ответа: 16 Автор ответа:  vito Разработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #16 | Добавлено: 21.04.06 19:50 |
|
Вовсе не "вот именно". События сокета никак не связаны с освобождением ресурсов.
Вот именно, тоько каких ресуросов? |
||
|
Номер ответа: 17 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #17 | Добавлено: 21.04.06 22:14 |
|
Робя! Харэ не по теме тереть!
В общем, плюнул я на средства Нэта в работе с сетью, т.к. они очень несерьёзные. Хотел написать винсок на основе API в C#. Так и там встрял. Мне надо, чтобы он не использовал окон (т.к. я планирую использовать его в службах), поэтому использую WSAXXXXXXXXX-функции, которые используют события. Но там надо создавать потоки, ждущие эти события - начиная отсюда начинается вторая жопа. Как вызвать корректно событие из потока, который не являлся создателем этого класса? Т.к. в событии может происходить взаимодействие с формами, что приведёт к исключению. Нашёл в инете вот это: http://forum.codenet.ru/showthread.php?threadid=21362 но ни фига не работает - исключение как возникало, так и возникает... |
||
|
Номер ответа: 18 Автор ответа: Sergey ICQ: 283551900 Вопросов: 1 Ответов: 74 |
Профиль | | #18 | Добавлено: 21.04.06 22:21 |
| Socket.Receive вроде если возвращает ноль то сокет закрылся. Это только в режиме когда Receive – ждет данные. | ||
|
Номер ответа: 19 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #19 | Добавлено: 22.04.06 00:22 |
|
Перешел на С#, потому что проще с API работать?
Как вызвать корректно событие из потока, который не являлся создателем этого класса? Не очень понятно.
Может что в этом роде нужно. protected ManualResetEvent manualResetEvent1 = new ManualResetEvent(false);
{ функция 1 // Создаем событие для функции OnManualEventSet // будет вызвана функция OnManualEventSet WaitOrTimerCallback callback = new WaitOrTimerCallback(OnManualEventSet); //Запускаем процесс в режиме ожидания. ThreadPool.RegisterWaitForSingleObject(manualResetEvent1, callback, null, Timeout.Infinite, true); } { функция 2 // Устанавливаем событие manualResetEvent1.Set(); } |
||
|
Номер ответа: 20 Автор ответа: EROS Вопросов: 58 Ответов: 4255  |
Профиль | | #20 | Добавлено: 22.04.06 01:07 |
|
Как вызвать корректно событие из потока, который не являлся создателем этого класса?
Если я тебя правильно понял, ты не можешь Cross-Thread Exeption обработать? Надеюсь, ты в обработчике Invoke используешь? |
||
|
Номер ответа: 21 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #21 | Добавлено: 22.04.06 01:50 |
А ну это .NET  ) WIN API форевер!!!!!
Ну куда это годится? Neco уже на C# перешел. Прослеживается тенденция, следующим будет С++. Теорема (пока не доказанная ) или аксиома.)
При решении сложных задач, безопасный код вырождается в опасный. ))
|
||
|
Номер ответа: 22 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #22 | Добавлено: 22.04.06 02:16 |
|
Neco уже на C# перешел.
Куда мир катится... |
||
|
Номер ответа: 23 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #23 | Добавлено: 22.04.06 02:40 |
|
EROS
Если я хоть немного понял, что хочет сделать Neco и как он это реализует, то C# ему не очень поможет. Сможет ли он это реализовать вопрос, а если и сможет то имхо через такую Ж
В НЕТ, как ты сам говорил, надо юзать родные функции (ну не считая самых простых API), все остальное лучше реализовать на "старых" технологиях. В НЕТ много недоделок, и MS знает о этом. Поэтому продолжается (и закончится ли?) поддержка уже не раз похороненных MFC, COM и т.д. После рекламной компании, пошли выпуски и другой литературы. Например Программирование на Microsoft Visual C++ .NET. MS Press 2003. О НЕТ (управляемых расширениях) там малюсенький кусочек в конце, все остальное обновленная классика, к НЕТ не имеющая никакого отношения . |
||
|
Номер ответа: 24 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #24 | Добавлено: 22.04.06 07:18 |
|
Если я тебя правильно понял, ты не можешь Cross-Thread Exeption обработать? Надеюсь, ты в обработчике Invoke используешь?
Там нет Invoke... Вот пример: public class clsMyClass
public event Eva() public sub New thNew as Thread=new Thread(addressof threda) thNew.Start(); end sub public sub threda raiseevent Eva() end sub end class Ну нету у меня Invoke, нету. По законам инкапсуляции, я должен сделать внутри класса что-то такое, чтобы потом пользуясь этим классом мне не пришлось в событии вспоминать о том, что у меня там многопоточность и надо проверять invokerequred. уже на C# перешел.
Между прочим, неплохая штука. В будущем планирую совмещать. В НЕТ, как ты сам говорил, надо юзать родные функции (ну не считая самых простых API), все остальное лучше реализовать на "старых" технологиях.
Дык API тут можно и не использовать - потоки-то я создаю "родным" способом. С помощью API я даю команду продвигаться им дальше или нет - это можно делать любым способом - пересечение потоков всё равно будет возникать. Короче, вилы в любом направлении. В общем, придётся мне рассылать контрольные пакеты на прикладном уровне и выдавать это за фичу - работаем в стиле MS. |
||
|
Номер ответа: 25 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #25 | Добавлено: 22.04.06 07:32 |
|
Хотя, честно говоря, вот эти вот ребята рассуждают довольно убедительно:
http://groups.google.kz/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/1d4d0ab56283b642/5a0f6b7764b4d076%235a0f6b7764b4d076 Может это действительно правильно, что у новых сокков нет такого события?.. |
||
|
Номер ответа: 26 Автор ответа: GSergВопросов: 0 Ответов: 1876 
|
Профиль | | #26 | Добавлено: 22.04.06 08:21 |
| Это неправильно, поскольку сокеты .net являются обёртками для wsock32, и при этом не предоставляют того функционала, который предоставляет wsock32. Недостающий функционал (см. ссылку) приходится добирать руками. | ||
|
Номер ответа: 27 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #27 | Добавлено: 22.04.06 08:28 |
| А ты ходил по линку, который я кинул? | ||
|
Номер ответа: 28 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #28 | Добавлено: 22.04.06 08:50 |
|
Обязательно.
Кстати, эта мысль там была озвучена в середине. Мысль в конце мне не понравилась. Мне не нравится, когда функциональность урезается, и это объясняется тем, что мне это никогда не понадобится. Откуда вы, блин, знаете, что мне может понадобиться? |
||
|
Номер ответа: 29 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #29 | Добавлено: 22.04.06 09:02 |
|
Напиши простенькое приложение, создай сетку (у меня была модемная сетка), соедини две проги и потом отключи мопед (выдерни штеккер).
Не знаю как у тебя, а у меня в проге, написанной на старом добром васике, ничего не происходит - подключение как было, так и есть (хотя винда видит, что теряет сеть). Из этого следует, что функционал обрезан по то место, по которое ему следует быть обрезанным и не более. Если событие дисконнекта наступает "иногда", то зачем нам такое событие? |
||
|
Номер ответа: 30 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #30 | Добавлено: 23.04.06 09:19 |
|
Долго думал над этой мыслью
Всё-таки в MSDN в описании FD_CLOSE одним из случаев прихода этого события является WSAENETDOWN (The network subsystem has failed). Потом всё же решил пообщаться на эту тему ещё. в TCP есть keep-alive
setsockopt(SO_KEEPALIVE) после этого, если кипалайв не придёт, винда сочтёт соединение порванным это вместо собственноручного пинга? угу Без него, событие придёт не всегда? видимо да. Зачем-то же он нужен |
||