Server Info

In this section, we discuss requirements for setting up your server to accept data from the reader. Note that we do not recommend specific programming languages or web servers. Consequently, this is a very general discussion that provides basic information to programmers needing to listen for connections from the reader and accept the data.

There are two primary server configurations that we support. TCP connections with a very simple data protocol; and, HTTP connections that support the TLS handshake for secure connections and require HTTP headers as part of the protocol. The following sections discuss some of the requirements for setting up each type of server.

Note that you will need to refer to AutoSens Macro Programs, Appendix A for the details that you need to know to properly parse the data sent from the reader to your server.

TCP Connections

TCP Connections are relatively straightforward. You simply need to set up a server that listens for a connection request on a specific TCP port and manages any data that comes through. There are two modes that this can operate in:

  • Streaming mode on Extreme readers where each data record from the reader appears in a single line terminated with a \r\n () pair. The reader does not close the connection after each read operation. Your server should listen for TCP connections, establish the connection when a request arrives, and process the data collection in individual threads.
  • Connection-oriented mode for other TCP-based connections on Extreme, Core, and Enterprise readers. Again, your server should listen for TCP connections on the configured communication port, connect when a request comes in, accept the connection and process the incoming data in separate threads, then close the connection. If you are only listening for data from one reader, you won't need to use threading, however, any time you need to collect data from multiple readers, you should expect the data to potentially arrive simultaneously from more than one reader. Note that the data from the reader will include a header line followed by one or more tag data records (one per line) terminated by a NULL (\0) byte at the end. The reader will initiate the closing of this connection, so an appropriate response from the server will result in a clean close rather than a connection reset.

If you are using a Linux computer for your server, or have one available for simple testing, you can use the "nc" utility program to test the TCP connections. Run "nc -l portnumber" on the command line in a Linux shell where portnumber is the port that you will configure the reader to use for sending data. So, for example, if your Linux computer is at 192.168.1.60 and you want to connect on port 6700, you would run "nc -l 6700" on your Linux computer and set the connection information on your reader to be "192.168.1.60:6700". Note that once the reader sends its data, it disconnects and nc will also return. For continuous testing, you can write a simple script the repeatedly runs the "nc" command in a loop.

HTTP Connections

Generally, HTTP Connections require a web server to collect data. Again, there are many web servers available with varying degrees of complexity to configure, to set up scripts for processing data and for managing the data that is collected. Consequently, we will only provide a few general pieces of information that might help getting started on this process.

  • If at all possible, configure your server to accept HTTP messages on port 80 or some other non-encrypted data channel. This will allow you to use tools such as Ethernet packet sniffers to see the actual data traffic sent from the reader to the server and the server responses. This makes debugging data messages more straightforward. Once you have data delivery working correctly, you can then switch to the TLS secure connection.
  • Our readers currently support TLS 1.2 with a wide variety of cypher algorithms. Once you switch to connecting with the TLS handshake, you can use the packet sniffer to debug potential issues.
  • The reader is sending HTTP POST requests to the server to deliver the data. The body of the HTTP POST message will typically be a JSON formatted text message, likely sent as chunked data. This generally should not be a problem since the underlying server code typically handles data chunking, however, if you custom code a server, you need to anticipate this.
  • The reader sends minimal HTTP headers. They are as follows:
    • POST /restpath HTTP/1.1
    • Host: hostname or IP address
    • Content-Type: application/json or text/plain (if using text rather than JSON encoding)
    • Transfer-Encoding: chunked
  • The reader is expecting a 200 OK HTTP response from the server. If the reader does not receive this response, it will not clear the internal tag list and old reads will accumulate from data report to data report.
  • You can send data back in the body of the HTTP response. This can be used as needed for debugging purposes by examining the data packets in a packet sniffer. The reader ignores this data and generally it should be turned off for production use since it will slow down the reader's ability to return to reading tags.