HTTP ping over UDP... - TCP-IP

This is a discussion on HTTP ping over UDP... - TCP-IP ; I have a simple UDP server that I wrote. I want to be able to simply ping it from a web browser by entering its IP and port into the address field of the web browser. The server will not ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: HTTP ping over UDP...

  1. HTTP ping over UDP...

    I have a simple UDP server that I wrote. I want to be able to simply
    ping it from a web browser by entering its IP and port into the
    address field of the web browser. The server will not have to return
    anything, all it will do is show a message on the server end that it
    was able to receive the request from the web browser. I know this is
    easily done if my server was using TCP, but can it be done using UDP?
    If I enter the IP/Port of the UDP server in my web browser now, the
    server never gets an incoming message, so I know it's not working as
    is, I'm just wondering if there is another way to do it?
    Thanks

  2. Re: HTTP ping over UDP...

    On 2008-10-15, hurricane_number_one@yahoo.com wrote:
    > I have a simple UDP server that I wrote. I want to be able to simply
    > ping it from a web browser by entering its IP and port into the
    > address field of the web browser. The server will not have to return
    > anything, all it will do is show a message on the server end that it
    > was able to receive the request from the web browser. I know this is
    > easily done if my server was using TCP, but can it be done using UDP?
    > If I enter the IP/Port of the UDP server in my web browser now, the
    > server never gets an incoming message, so I know it's not working as
    > is, I'm just wondering if there is another way to do it?


    Remember that TCP ports and UDP ports are entirely separate. That
    it TCP port (say) 34 is distinct from UDP port 34. Any port number
    that you put in the address box of your web browser goes to the
    TCP port. AFAIK there's no way to redirect the browser to the UDP
    port, which wouldn't make any sense for the higher-level protocols
    that the browser supports anyway.

    --
    Andrew Smallshaw
    andrews@sdf.lonestar.org

  3. Re: HTTP ping over UDP...

    >I have a simple UDP server that I wrote. I want to be able to simply
    > ping it from a web browser by entering its IP and port into the
    > address field of the web browser. The server will not have to return
    > anything, all it will do is show a message on the server end that it
    > was able to receive the request from the web browser. I know this is
    > easily done if my server was using TCP, but can it be done using UDP?
    > If I enter the IP/Port of the UDP server in my web browser now, the
    > server never gets an incoming message, so I know it's not working as
    > is, I'm just wondering if there is another way to do it?
    > Thanks


    Browsers talk HTTP (and FTP and maybe other protocols) over TCP, not UDP.

    You didn't tell why you insist on using a browser, but if it's for the
    convenience that it's readily available everywhere or so, you could consider
    portable-apps version of UDP port scanners that you cary on your USB stick
    or download from the internet.

    Or you could (ab)use built-in OS commands that use UDP.

    For example, you could use the DNS resolver command (e.g. nslookup) and tell
    it to use your serve iport as DNS server.

    Your server will then receive a DNS request via UDP. You'll have a timeout
    at the client because you don't return a response, but you sent a UDP
    datagram at your target.


  4. Re: HTTP ping over UDP...

    On Wed, 15 Oct 2008 09:31:56 -0700 (PDT), hurricane_number_one@yahoo.com wrote:
    > I have a simple UDP server that I wrote. I want to be able to simply
    > ping it from a web browser by entering its IP and port into the
    > address field of the web browser. The server will not have to return
    > anything, all it will do is show a message on the server end that it
    > was able to receive the request from the web browser. I know this is
    > easily done if my server was using TCP, but can it be done using UDP?
    > If I enter the IP/Port of the UDP server in my web browser now, the
    > server never gets an incoming message, so I know it's not working as
    > is, I'm just wondering if there is another way to do it?


    You are setting up rules for your problem which make it impossible to
    solve: you want a TCP-only application (URLs can be of a few different
    kinds, but all translate to TCP-based protocols AFAIK) to talk to a
    UDP-only application.

    What task do you want to solve, on a higher level?

    You are not writing a web server I assume, so even if your server was
    a TCP server, the person using the browser would at best see different
    error messages if it was alive or not.

    /Jorgen

    --
    // Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

  5. Re: HTTP ping over UDP...

    On Oct 16, 1:15*pm, Jorgen Grahn wrote:
    > You are setting up rules for your problem which make it impossible to
    > solve: you want a TCP-only application (URLs can be of a few different
    > kinds, but all translate to TCP-based protocols AFAIK) to talk to a
    > UDP-only application.



    Not necessarily. Consider the DNS: or TFTP: URI schemes. Of course
    you'll need to find a browser that actually supports it (FWIW, I tried
    a couple, and had no luck with DNS.

  6. Re: HTTP ping over UDP...

    In article <4d378068-780a-4483-ae17-bf3bf8481e13@f63g2000hsf.googlegroups.com>,
    mockturtle wrote:

    >Maybe I did not explain myself. Let me try again: the FHS (fake HTTP
    >_server_)
    >runs on the _same_computer_ where the UDP server runs (actually,
    >it could run on another one, but always a computer under the control
    >of the OP), wait for a connection on the port 80 and when it receives
    >it, it sends the request to the UDP server (and maybe reply an empty
    >page to the HTTP client).


    That does not check whether the client can send a UDP packet to the
    UDP server and then get a UDP response from the UDP server, both
    through firewalls, routing, etc.


    >It is the _FHS_ that sends to the UDP port. The user device needs
    >only
    >to reach the TCP port 80.


    That tells no one anything about problems in the client or the network
    between the client and the UDP server. If the client, evidently a
    "smart phone" sold as useful for "surfing duh net," cannot reach TCP
    port 80 on any competently run system on the global Internet, then
    something is so obviously and badly broken that it's not worth talking
    about. The problems of a client on the same host as the UDP server are
    also too obvious to talk about.


    >I do not know if this setup could work, I think it depends on the
    >details of the OP's problem.


    It would work, because one way or another you can tunnel anything
    over or through HTTP.

    > If, for example, the goal was to
    >check if some firewall/NAT/whatever is blocking the UDP
    >path, I agree that this test does not make much sense. If the goal
    >is to check if the UDP server is alive, this can help.


    No, it would not help to expect buyers of this small application to
    test the health of the servers. They would and should expect
    the owner/operators of the servers to use standard tools to raise
    alarms when the servers have problems before many users notice.
    More than that, the buyers of this application would and should
    expect the seller to monitor the health of the UDP servers from
    several (or more than several) well separate addresses on the
    Internet to detect and deal with connectivity problems. See for
    example http://www.google.com/search?q=nagios
    Still more, users would and should expect the application protocol to
    include robust mechanisms to switch to a working server should most of
    the servers (not to mention any single server) fail or appear to fail
    because of Internet problems.

    The initial plans for any competent service include detecting and dealing
    with server failures, including not only Internet and host computer
    problems, but active enemies including DoS attacks and too much load
    from customers. If your plans do not included explicit steps to deal
    with such things, then you are planning on failure. Either you expect
    your enterprise to never work, or you expect it to start to succeed and
    then be destroyed by Murphy's Law, the script kiddies, or its own success.

    I realize I may be unforgiving, but such "optimistic" designs are
    the hallmark of the Redmond School of Computer Software Design.


    Vernon Schryver vjs@rhyolite.com

+ Reply to Thread