Development Tools

• Code/Help Repository:
  • Getting the code
  • Developing with Git
  • Merging a PR
  • Git FAQs
  • Intro to GitHub Desktop
• Building Tools:
  • Ant
  • NetBeans
  • Eclipse
  • IntelliJ IDEA

Code Structure

• Introduction
• Names and Naming
• Application Structure
• Code Structure Patterns
• Swing Structure
• External Connection Structure
• Application Preferences
• Profile Files
• Threading
• Use of XML
  • XML Schema
  • XSLT Formatting
• Web Site
• Javadocs
  • Name Index
  • Packages
  • Classes

Techniques and Standards

• Recommended Practices
• Continuous Integration
• Internationalization
• Logging & Error Handling
• Unit testing with JUnit
• Documentation using Javadoc and UML
• Run the SpotBugs static analysis tool
• Providing help using JavaHelp
• Portable Filename Method
• XML Persistance

Help and Web Site

• Providing Help using JmriHelp
• The JMRI Web Site
• Updating JMRI Web and Help
• Creating Help for New Hardware
• Program Documentation Using Javadoc

How To

• Extend JMRI
• Add a New System
• Add a New Type

Functional Info

• Turnout Feedback
• Network Connections
• How the startup scripts work

Background Info

• Technology Roadmap
• Survey of JVM Capabilities
• Usage Poll, Spring 2007

Donate to JMRI.org

JMRI Code: Network Access

This page describes various forms of network access available in JMRI. More capabilities are added all the time, so please check with the user group for up-to-date information.

Methods of Network Access

JMRI interacts with networks in two basic forms: downstream connections and upstream connections.

A downstream connection allows JMRI to connect to a layout via a network for operations and control. This uses a network connection to do the same kinds of things that are often done via serial RS232 and USB links. In the client-server architecture, JMRI is usually one of potentially many clients connecting to a server in this case.

An upstream connection allows other devices to command JMRI over a network connection. In this case, the network connection allows other devices and/or programs to do things that are normally done via scripts and the graphical user interface. In the client-server architecture, JMRI is usually a server with one or more clients connecting to it in this case.

Note that the JMRI JSON and Web servers can be used by other layout-connected devices such that both the JMRI application and the other device can be simultaneously "downstream" and "upstream" of each other for specific aspects of layout control. In this case, although JMRI is functionally the server (in a client-server architectural sense), it is receiving layout updates from the client device.

In the rest of this page, we provide links to the various examples of those two general areas.

Downstream (networked layout hardware) connections

• LocoNet systems
  • LocoNet RMI client server connection

    This uses Java RMI to provide client-server access to the LocoNet message stream on another JMRI instance.

  • LocoNet over TCP

    This uses LocoNet over TCP to provide client-server access to the LocoNet message stream from various servers.

• C/MRI
  • This exchanges the C/MRI poll/response protocol via a terminal server
• CAN via GridConnect Network Interface
  • This network interface can be used for the OpenLCB Hub Control
• CAN via MERG Network Interface
  • The network interface can be used for the CANEther, CANGC1e, CANPi, CBUS® Server, or CBUS® Hub Control
• EasyDCC
  • This exchanges the EasyDCC ASCII command station protocol via a terminal server
• JMRIClient
  • Via network connection to a JMRI Simple Server
• NCE
  • This exchanges the NCE command station protocol via a terminal server
• SRCP
  • Via network connection to SRCP server
• ECOS
  • Via network connection to ECOS command station
• XPressNet
  • Via network connection to an XnTcp adapter
  • Via network connection to the Lenz LIUSB Server (Windows only)

Upstream (networked JMRI operations) connections

• Built-in web server (code)

  This is advertised on Bonjour/Zeroconf as a "_http._tcp.local." service. In particular, this contains the JMRI JSON protocol, which allows web browsers to monitor and control a layout by accessing a JMRI JSON Servlet. It also includes facilities for displaying and clicking on any open JMRI window.

• Via Python/jython scripting
• For remote throttles such as the iPhone or Android. (code) (WiThrottle product website) (Android Engine Driver page)

  This is advertised on Bonjour/Zeroconf as a "_withrottle._tcp.local." service.

• Via running JMRI as an Enterprise Java Bean
• Via providing a LocoNet RMI server.

  This is advertised on Bonjour/Zeroconf as a "_jmri-locormi._tcp.local." service.

• Via providing a LocoNet over TCP implementation.

  This is advertised on Bonjour/Zeroconf as a "_loconetovertcpserver._tcp.local." service. (Name pending approval from the original protocol developers)

• Via providing an SRCP server implementation.

  This is advertised on Bonjour/Zeroconf as a "_srcp._tcp.local." service.

• Via providing a JMRI Simple Server implementation.
• Via providing an OpenLCB Hub implementation.

  This is advertised on Bonjour/Zeroconf as a "_openlcb-can._tcp.local." service.

• Via providing a CBUS Hub implementation.

  This is advertised on Bonjour/Zeroconf as a "_cbus-can._tcp.local." service.

See also the DNS-SD page for more information on Zeroconf/Bonjour/"DNS Service Discovery" networking.

Search "man dns-sd" for more information on the dns-sd debugging command-line tool.

CBUS® is a registered trade mark of Dr Michael Bolton

---