Results for connect-ping

Monitor `clamd` from the luxury of your existing OkComputer setup! This check will make noise when the daemon does not respond to messages. It makes a socket connection, sends a PING and waits for a PONG. If any of that does not occur, you'll know it.

# Netchk Simple tool to troubleshoot internet connectivity issues. This tool verifies: - your computer has at least one IP address - you have at least one DNS configured - you can reach the configured nameservers - the nameservers can resolve hosts Finally, some ICMP ping statistics are presented with average durations and error rates. ## Installation ```sh gem install netchk ``` ## Usage Just run `netchk` from your terminal and basic diagnosis will start showing you progress and any error if present. Note: On Linux system, this gem requires `sudo` to perform the ICMP ping operations. On macOS, this is not needed. You also can configure how netchk verifies your connections by configuring a `~/.netchk.yaml` or `~/.netchk.yml` file like below. ```yaml # Settings to test DNS server connectivity. dns: # Path to resolv.conf file to check presence and connectivity of DNS. # Path should be absolute to avoid issues when running netchk # from different directories. resolv.conf: /etc/resolv.conf # Settings to test DNS resolution. resolv: # Path to resolv.conf file to use for testing DNS resolution. # Path should be absolute to avoid issues when running netchk # from different directories. It is advised to be the same # as dns.resolv.conf. resolv.conf: /etc/resolv.conf # The list of domains to test for DNS resolution. domains: - google.com - youtube.com - facebook.com # Settings to test icmp ping. icmp: # A list of hosts to ping with ICMP. It is advised to use # IP addresses instead of domains to rule out any issues with # DNS resolution, which is tested separately. hosts: - 1.1.1.1 - 8.8.8.8 # The number of ping to issue each host. count: 20 # The duration in seconds to wait between each ping. # Setting this value too low might cause timeouts. interval: 0.2 ``` Each value is optional. If one is missing the default value will be used. The file above shows the default values. ## Contributing Bug reports and pull requests are welcome on GitHub at https://github.com/moray95/netchk.

A production-grade Ruby client for Nostr Wallet Connect (NIP-47). Handles the Nostr protocol, NIP-04 and NIP-44 v2 encryption, secp256k1 key derivation, Schnorr signing, and — most importantly — a reliable long-running WebSocket connection to the relay with heartbeat pings, forced recycle, exponential backoff, and SIGTERM handling. Developers call `pay_invoice`, `make_invoice`, `lookup_invoice`, etc. and `subscribe_to_notifications { |n| ... }` — the transport reliability is hidden.

Em-resque is a version of Resque, which offers non-blocking and non-forking workers. The idea is to have fast as possible workers for tasks with lots of IO like pinging third party servers or hitting the database. The async worker is using fibers through Synchrony library to reduce the amount of callback functions. There's one fiber for worker and if one of the workers is blocking, it will block all the workers at the same time. The idea to use this version and not the regular Resque is to reduce the amount of SQL connections for high-load services. Using one process for many workers gives a better control to the amount of SQL connections. For using Resque please refer the original project. https://github.com/defunkt/resque/ The library adds two rake tasks over Resque: * resque:work_async for working inside the EventMachine

HttpLoader is a powerful, high-concurrency performance and load testing console tool. Built on asynchronous Ruby, it evaluates server limits by opening massive numbers of persistent connections and holding them open. It utilizes event-driven I/O with optional periodic ping requests to keep connections active, allowing you to rigorously benchmark maximum concurrent socket capacity with precision and minimal client-side overhead.

A daemon, running in background on a Linux router or firewall, monitoring the state of multiple internet uplinks and changing the routing accordingly. LAN/DMZ internet traffic (outgoing connections) is load balanced between the uplinks using Linux multipath routing. The daemon monitors the state of the uplinks by routinely pinging well known IP addresses (Google public DNS servers, etc.) through each outgoing interface: once an uplink goes down, it is excluded from the multipath routing, when it comes back up, it is included again. An uplink may be assigned to a priority group: lower priority uplinks will only be used if all higher priority ones are down. That's useful to only use pay-per-traffic uplinks if no regular uplink is working. All of the routing changes are notified to the administrator by email. Fault Tolerant Router is well tested and has been used in production for several years, in several sites. See https://github.com/drsound/fault_tolerant_router for full documentation.

# Quick Start The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS). Let’s assume that the access token provided by your account manager is “TOKEN”. Here’s how to get the list of ids of all your invoices from the first week of August with a shell script: ```bash query="end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00" curl -i "https://api-eu.getaround.com/owner/v1/invoices?${query}" \ -H "Authorization: Bearer TOKEN" \ -H "Accept:application/json" \ -H "Content-Type:application/json" ``` And here’s how to get the invoice with the id 12345: ```bash curl -i "https://api-eu.getaround.com/owner/v1/invoices/12345" \ -H "Authorization: Bearer TOKEN" \ -H "Accept: application/json" \ -H "Content-Type: application/json"" ``` See the [endpoints section](#tag/Invoices) of this guide for details about the response format. Dates in request params should follow the ISO 8601 standard. # Authentication All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager. Unauthenticated requests will return a 401 status. # Pagination The page number and the number of items per page can be set with the “page” and “per_page” params. For example, this request will return the second page of invoices, and 50 invoices per page: `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` Both of these params are optional. The default page size is 30 items. The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page. Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel="next" ``` # Throttling policy and Date range limitation We have throttling policy that prevents you to perform more than 100 requests per min from the same IP. Also, there is a limitation on the size of the range of dates given in params in some requests. All requests that need start_date and end_date, do not accept a range bigger than 30 days. # Webhooks Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations. ### Setup To set up an endpoint, you need to define a route on your server for receiving events, and then <a href="mailto:owner-api@getaround.com">ask Getaround</a> to add this URL to your account. To acknowledge receipt of a event, your endpoint must: - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate. ### Testing Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below: <form action="/docs/api/owner/fire_ping_webhook" method="post"><input type="submit" value="Send Ping Event"></form> You should receive the following JSON payload: ```json { "data": { "ping": "pong" }, "type": "ping", "occurred_at": "2019-04-18T08:30:05Z" } ``` ### Retries Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned. ### Verifying Signatures Getaround will also provide you with a secret token, which is used to create a hash signature with each payload. This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this: ```ruby require 'sinatra' require 'json' post '/payload' do push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end ``` The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this: ```ruby post '/payload' do request.body.rewind payload_body = request.body.read verify_signature(payload_body) push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end def verify_signature(payload_body) signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body) return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ``` Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however: No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body. Using a plain `==` operator is not advised. A method like secure_compare performs a "constant time" string comparison, which renders it safe from certain timing attacks against regular equality operators. ### Best Practices - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering.

No description provided.

No description provided.

No description provided.

No description provided.

No description provided.

No description provided.

No description provided.

No description provided.

No description provided.

No description provided.