Home AMX User Forum AMXForums Archive Threads AMX Hardware

Proxy Server?

Does anyone know if you can enter a proxy server address into an NI system? I have a High School that restricts access to the internet and am trying use the Interent Inside Time Server to keep the clock settings accurate. He can probably move the system to another network, but I was wondering if anyone else has ever run into this issue.


  • Options
    jeffacojeffaco Posts: 121
    Hmm, I doubt it ...

    As the one that wrote the core code to the time server (AMX picked it up and distributed it as i!-TimeManager with my blessings): unless they made significant changes (and last I was told, they didn't), I doubt that a proxy server would work. Unless, I suppose, the proxy server could be configured to automatically redirect NTP traffic to the Internet (but then the proxy would be "invisible" to i!-TimeManager).

    Quite simply, I didn't anticipate this need. It never even entered into my mind.

    On the bright side, the code that AMX picked up is actually open source software, available at:


    If you wanted to make the changes to support a proxy configuration, that's the power of open source. And, if you were to send changes back to me, I'd be happy to merge them in with the original sources, thus benefiting others.

    Other options: if the High School has some server system (likely), they may want to simply deploy a time server on one of their Windows or Unix systems. It's no security risk (it makes an OUTGOING connection - no incoming connection needed), and then you have a local time source that you can just hit as needed.

    Or you can also perhaps ask them to deploy an NTP server on their gateway router. Cisco routers support this out of the box, and I imagine certain other routers do as well.

    Hope this helps,

    -- Jeff
  • Options
    Chip MoodyChip Moody Posts: 727
    Re: Proxy Server?
    Originally posted by wgreen
    Does anyone know if you can enter a proxy server address into an NI system?

    IMHO, not having/adding support for this is one of those things that has made me go "what the heck is AMX thinking". I asked about this years ago, shortly after NetLinx came out, when I wanted to do this very thing on my own company's network. I was told not to hold my breath. Just seemed really suprising to me considering how many corporate networks require this.

    - Chip
  • Options
    jeffacojeffaco Posts: 121
    If this is a major issue on corporate networks, you'd think that the corporation could do something in terms of a segmented LAN or some other arrangement to give the NetLinx hardware the access that it needs.

    After all, at the company I work for: If I demonstrate a business need for some special type of access, I generally get it unless it would totally compromise network security or something ...

    Another option: you could write something easily enough, I suppose, as a general service, if this is really important to you. When I was dealing with an MVP-8400 issue with long paths, I had considered working on a WWW "redirection" server. It would basically be a module that would listen on port 81 (since port 80 is taken), receive requests for images, and redirect to the "real" server with long paths. We ended up working around the issue in a different way, though, to avoid the issue completely.

    Anyway: if you needed this, you could write a "redirection" server that would accept a connection on a port of your choosing and redirect to a proxy server with whatever rule set you cared to implement. The nice thing about this solution is that it's "generic", and would work for anything. Get the response back, redirect back to the source.

    Of course, I'm not sure if this would work without looking at proxy servers a lot more specifically. First, I'm not sure if a proxy server will "proxy" UDP rather than TCP (SNTP, the protocol that i!-TimeManager uses, works with UDP most often). Second, I'm not sure what the "standards" are for proxy, and how easily various applications can be adatped. For example, to WWW to "proxy", you need application support, and you often need JAVA scripts to change how the behavior works.

    This is WAY beyond what AMX should do, IMHO. Should they be writing proxy system-specific code for all their modules? If so, what if you're using some other proxy product, and if it's behavior is different? Where do they draw the line?

    I can understand why they'd say "don't hold your breath". I'm not sure you could get a lot of agreement in the AMX community on what should be written, and how it should work.
  • Options
    frthomasfrthomas Posts: 176
    Well, the issue of proxy server is certainly a hot one.

    Now for the particular TIME problem, any decent network should support this service on its LAN. The ntp protocol is designed that way, so that a machine on the network gets its time synced on the WAN and then other network machines ask this machine and not the WAN server. F.e. some ADSL routers propose that service. On a High School network, one of the file servers could perform that service. There are even standalone time servers available that use a GPS antenna to get their time, if you really are adverse to a WAN connection (Datum is a manufacturer).

    So in defense of Jeff and AMX for the time module, I don't think it makes a lot of sense to build a proxy option into it. I am not even sure ntp proxying is really defined.

    wgreen, you may want to ask the school network admins if they support it. Any UNIX server does out of the box.

  • Options
    jeffacojeffaco Posts: 121
    LOTS of things support NTP (well, SNTP *, the simplistic implementation that I decided to do in my TimeSync module, later picked up by AMX for i!-TimeManager - see below if you're really curious on why I picked SNTP).

    Windows, UNIX (all flavors), and routers are examples. In my usage and history with NTP:

    I first had my module hit my Windows server. While server code doesn't ship with Windows, shareware code (TARDIS, for example) is available VERY cheaply to do this. There might also be freebie solutions, but I always used TARDIS on Windows.

    After a while, I configured my Cisco router (it sits at the border of my network and serves as a firewall as well) to be an NTP server. So it goes out to the internet and sends a packet every 1024 seconds or so to be sure it's still "in sync" with Internet Stratum 1 servers. Then I have lots of machines hit my Cisco router for it's time (Windows itself does this - this is part of what service w32tm does), as does my UNIX system, my AMX system, my print server, my UPS, etc, etc. Basically, anything that cares about the time gets it from my router.

    So, in short: Many routers have NTP servers built in. Windows has shareware software (TARDIS and others) to serve this function. For UNIX, it's built in *and* generally enabled by default unless you go out of your way to disable it (at least for most distributions). Note that many UNIX distributions will now optionally install a firewall; if you install a firewall, be sure to configure it to allow for clients to request time via NTP or SNTP.

    -- Jeff

    * So, why does AMX only support SNTP rather than NTP (same ports, just a slightly different protocol; all NTP servers support SNTP as well as NTP). The NTP protocol allows a machine to get VERY close to the actual time and stay there (well, 50ms or so of the actual time).

    For example, Cisco routers generate an internal clock frequency to run at. As the NTP server syncs, it will change that internal frequency to keep it closer and closer to "real time", so that when it goes to get updates from the Internet, no time adjustment is actually needed. NTP even takes packet delays into account. Eventually, the internal clock frequency becomes so close to "real time" that no adjustments are needed, that gets saved into NVRAM, and at that point, the Cisco can run for weeks without updates and not experience clock drift.

    SNTP is a simplified protocol to let you get very close, but not quite as exact. And then my implementation is worse than that: my implementation generally discards the fractional second portions of the packet.

    Why? Well, NetLinx interfaces only allow you to set the time with an accuracy of one second (you can't set fractions of a second). So I basically just ignore the fractional field and set the time for the actual number of seconds since 1900 that's encoded, adjusted for local time zone and DST. I don't even bother accounting for packet delay times. Those are generally under one second (or the packet usually gets dropped), so it's pointless since NetLinx interfaces lack precision to allow me to do anything with that information.

    If NetLinx ever allowed for: (1) More accurate setting of the time, and (2) Adjustments to the NetLinx clock to allow it to sync with an external time source, then I'd revisit the code and extend it to be as good or nearly as good as what you'd find on routers or computers.

    But as is, it's within 1-2 seconds of the NIST time (set by atomic clock), which is likely fine for most applications! ;-)
Sign In or Register to comment.