• dynip.com protocol

    From mark lewis@1:3634/12 to all on Mon Mar 26 02:43:34 2001
    i want to take a second to apologize for being a little "short" recently... it just didn't dawn on me that being linked to a backbone hub that one could still
    miss messages... quitting smoking and drinking doesn't help one's outlook/attitude, either... i'm sorry...

    anyway, i thought i'd also take a moment to post some of the protocol info of dynip.com's updater... this is the methodology of the dynip.com protocol... details are further in the documentation included with the source code...



    2.0 Client/Server Exchange

    2.1 Overview

    The client interacts with the DynIP Registration server to obtain a new sub-domain registration, delete an existing sub-domain registration or request sub-domain registration information that has been previously submitted (a so-called ``refresh'' operation). After a successful sub-domain registration, the client only needs to periodically send ``keep active'' packets to the DynIP
    server.

    2.2 Transport

    The DynIP server assumes that all communications regarding sub-domain registration, refresh and deletion are performed using the TCP transport protocol on privileged port 252 (decimal). Activation of a sub-domain registration occurs when the client sends a KEEPACTIVE packet to the DynIP name
    server using the UDP transport protocol on privileged port 53 (decimal). The client is responsible for listening on a dynamically determined UDP port for Server Message Packets (SMP).



    everything else in the documentation digs into the nitty gritty details... but even so, this port should not require knowledge of those details, as far as i can see... in reality, i don't see this port requiring a lot of work at all... maybe some additions to support drive letters in addition to paths but i don't see that as necessary at this point...

    my main goal is to try to get this client operational and see if it has the same problems that another client i have is experiencing... the other client has been in place and running without problems for three years... i don't know if this problem stems from w3c/fp40 or what but it's a problem, nonetheless and
    i need a solution... besides, the author of the other client package hasn't been heard of in over two years and didn't release the sources at that time like he stated he would do...

    )\/(ark


    * Origin: (1:3634/12)