C#, Тестирующий активное интернет-соединение. Проверка с помощью ping-запросов google.com
Это неправильный путь. В Apex и в Oracle в целом столбцы определяются при разборе запроса. Если вы измените основную структуру, ваш запрос должен быть обработан повторно, и только тогда столбцы изменятся.
Подумай об этом. Если первый столбец в вашем наборе результатов был DATE и у вас были настроены атрибуты столбца Apex для форматирования и отображения этих данных, тогда ваш запрос изменился на NUMBER, и неясно, что произойдет.
Что вы, вероятно, хотите сделать, это создать свой регион на основе функции, которая возвращает SQL-запрос в виде VARCHAR2. (Я думаю, что вы можете сделать это в 18.x; я все еще в основном использую 5.2.) Ваша функция анализируется при отображении региона. Вы даже можете использовать другую функцию для возврата списка заголовков столбцов, разделенных двоеточиями, если имена динамические.
6 ответов
Why ping Google? The only server you really care about is the web server you want to talk to, right? So ping that instead. That way, you can notify the user if anything is wrong between them and the web server - that's the only thing that matters.
If something goes wrong with the internet which means that the user can only do anything within their own town, you may not be able to reach Google but if you can still reach the web server you're interested in, why report a problem? On the other hand, if the web server goes down but Google doesn't, why would you not want to tell the user that there's a problem?
Likewise, why use a ping? Why not send an HTTP request to a known URL on the web server? After all, if the network is up but the web server process itself is down, surely that's just as bad as the user's network going down.
EDIT: I hadn't noticed in the question that you were repeating this every half second. That's really not pleasant for anyone. Surely once a minute is often enough, isn't it?
I have an app that needs to do something similar. We have a bit of a different architecture in place, namely a pub/sub message bus. For those applications interested in hearing "heartbeats" from the various services, we allow them to register their interest with the bus. Every few second or so, each service will publish a health state message that consumers will then receive. If the consumers do not receive a health state message for a certain amount of time, they can take appropriate action until they hear it again.
This setup is much more scalable than polling the server or even worse pinging it. Imagine if you had 100 or 1000 clients all polling or pinging your sever every few seconds. Bad.
I might be missing something but, Why do you need to test that the server is up and the web service running before you need to use it? If you call a method in your web services and you don't get a timely response, then take what ever action you see fit or need?
It just seems over engineering of the design.
[edit]
Thanks for the clarification robUK. You should listen to NET Rocks podcast episode 'Udi Dahan Scales Web Applications!' (date 12/08/2008). They discuss adding a GUID to a request and wait until you get the same GUID in the response. Maybe you could fire it off every second for say 10 attempts and if you don't get a response back (with the GUID attached) after 10 attempts, then take the required action?
Good luck with it..
It'd suggest to put more than 0.5s, because sometimes your lataency can get higher. I sometimes have even 3.5s on DSL.
Проверьте этот повторяющийся вопрос, на который есть хороший ответ, не требующий проверки связи:
C # - Как проверить сетевое соединение
Вы можете подписаться на Систему. Net.NetworkInformation.NetworkChange.NetworkAvailabilityChanged и только тогда, когда оно указывает на то, что сеть не работает, выполните ping / веб-запрос к серверу, чтобы узнать, доступен ли он.
Лучше проверить, есть ли вы в сети, чем беспокоить сервер, пингуя его. См. например Определить Интернет V. локальное LAN-соединение. Если вы работаете в Windows 7 / Server 2008 R2, вы можете получить событие при изменении подключения, что будет гораздо приятнее для всех, чем постоянные пинги и опросы.