{"id":1139,"date":"2019-08-14T16:19:46","date_gmt":"2019-08-14T23:19:46","guid":{"rendered":"https:\/\/portal.staylinked.com\/sl\/kb\/?post_type=ht_kb&p=1139"},"modified":"2025-04-16T09:35:24","modified_gmt":"2025-04-16T16:35:24","slug":"session-specific-log-files","status":"publish","type":"ht_kb","link":"https:\/\/portal.staylinked.com\/sl\/kb\/knowledge-base\/session-specific-log-files\/","title":{"rendered":"Log Files – Session-Specific Log Files"},"content":{"rendered":"\n

All StayLinked clients record a client log, but the StayLinked server\ncan also be configured to record additional log files for each session. These server-side\nsession-specific files are stored in the server\u2019s logs subdirectory and include\nthe IP address of the related device as part of the file name. An example of a\nfile name would be StayLinkedHandler.192.168.12.142.log.<\/p>\n\n\n\n

When gathering client files, the StayLinked Administrator will store them in the files subdirectory. Log files gathered from the server are written to the Administrator\u2019s local logs subdirectory. <\/p>\n\n\n\n

Client<\/h2>\n\n\n\n

Default state:<\/strong> Enabled as staylink.log
Maximum size:<\/strong> 512KB with optional client settings to adjust size.
Cleanup: <\/strong>512KB or device cold reset
History:<\/strong> None<\/p>\n\n\n\n

The StayLinked client\u2019s job is to reliably display screen updates and submit user inputs to the server in the order there are received. The client log shows the device\u2019s point of view for communication. It records startup and connection details as well as interruptions in the network. More information on communication interruptions can be found in the Client-Server Communications Guide<\/a>.<\/em><\/strong><\/p>\n\n\n\n

Stop and error events in the\nclient are also recorded here, but application errors are not recorded.\nApplications run on the host, not as part of the StayLinked client which simply\npaints whatever the server sends out to the device screen.<\/p>\n\n\n\n

Log events are recorded as [i]\ninformation, [e] error, or [d] debug. Debug events should only appear when\nenhanced\/verbose logging is enabled. Errors are uncommon, but may help identify\nsources when issues are encountered. The informational events range from\nstandard messages and confirmations to entries about network and connectivity\nstatus.<\/p>\n\n\n\n

The following are examples of important\nclient log file contents.<\/strong><\/p>\n\n\n\n

During startup, dozens of general client and device details are recorded:<\/strong>
Date Time:[i] *** StayLinked v12.1.0(130) [Feb 19 2016] ***
Date Time:[i] device_type=MC9190C_E5
Date Time:[i] espcontrol version=10.0.0(116)
Date Time:[i] ip addr: 10.10.225.187<\/code><\/p>\n\n\n\n

Once a connection is initiated, the client logs the connection request:<\/strong>
Date Time:[i] ------- host connect -------
Date Time:[i] connect: h=192.168.100.63, p=3006<\/code><\/p>\n\n\n\n

A session ID of 00000 is a request for a new session. A client recovering an existing session will request a specific session ID:<\/strong>
Date Time:[i] session-requested=513EA<\/code><\/p>\n\n\n\n

Network interruptions are an important part of the client log:<\/strong><\/p>\n\n\n\n

[Out of Range]
Date Time:[i] <- oor_beg
Date Time:[i] <- oor_max - AP=[00:A0:F8:61:D7:D2]
Date Time:[i] <- oor_abt
Date Time:[i] <- oor_end<\/code>
<\/p>\n\n\n\n

[Linking]
Date Time:[i] <- oos_beg
Date Time:[i] <- oos_max - AP=[00:08:A2:01:64:00]
Date Time:[i] <- oos_abt
Date Time:[i] <- oos_end<\/code><\/p>\n\n\n\n

Out of Range events are recorded\nwhen the device operating system reports that the radio is not associated to\nnetwork. Linking events are recorded when packets are not returning in a timely\nmanner. Each event is recorded as a begin, displaying a character in the upper\nright corner of the screen. If the issue continues, the log will record a \u2018max\u2019\nwhich means the user is being presented with a retry counter. The event will\n\u2018end\u2019 when the network access is returned or when the user presses a key to\ncancel, recorded as an \u2018abort\u2019.<\/p>\n\n\n\n

More details on these events can\nbe found in the technical references for Client-Server Communications and Host\nTimeout.<\/p>\n\n\n\n

Disconnections from a session are recorded to the log with a disconnect code:<\/strong>
Date Time:[i] client disconnect, code=110
Date Time:[i] host disconnect, code=110<\/code><\/p>\n\n\n\n

The following is a list of the possible disconnect codes:<\/p>\n\n\n\n

CLIENT_DIS_SERVICE<\/td>100<\/td><\/tr>
CLIENT_DIS_OOR_ABORT<\/td>110<\/td><\/tr>
CLIENT_DIS_OOS_ABORT<\/td>120<\/td><\/tr>
CLIENT_DIS_NETM_ABORT<\/td>130<\/td><\/tr>
CLIENT_DIS_SCRIPT<\/td>140<\/td><\/tr>
CLIENT_DIS_FROM_USER<\/td>150<\/td><\/tr>
CLIENT_DIS_SWITCH_SESS<\/td>160<\/td><\/tr>
CLIENT_DIS_FROM_ADMIN<\/td>170<\/td><\/tr>
CLIENT_DIS_CLIENT_EXIT<\/td>180<\/td><\/tr>
CLIENT_DIS_SESSION_ENDED<\/td>190<\/td><\/tr>
CLIENT_DIS_SESSION_NOT_FOUND<\/td>195<\/td><\/tr>
CLIENT_DIS_TRANSFER_SESS<\/td>200<\/td><\/tr>
CLIENT_DIS_SERVERS_LIST<\/td>210<\/td><\/tr>
CLIENT_DIS_RECONNECT<\/td>220<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Session<\/h2>\n\n\n\n

Default state:<\/strong> Disabled, enabled in server settings for session, handler and socket logging.
Maximum size:<\/strong> Per Server Settings
Cleanup:<\/strong> Deleted and restarted after reaching max size
History:<\/strong> None (see section\n1.4 for snapshot)<\/p>\n\n\n\n

The session log records transactions between the StayLinked server and\ntelnet host. Each outbound transaction submitted to the telnet host is recorded.\nTelnet host responses are noted, but the log file does not include the contents\nof those return presentation events. The session log is an excellent source to\ndetermine how long the host application is taking to respond to user inputs.\nTimestamps can help review this file for each input and the corresponding\nresponse or host event.<\/p>\n\n\n\n

Viewing the host\nresponses is best accomplished using the handler or proxy log files. Minor\nadjustments have been made to the following example for readability and\ndemonstration.<\/p>\n\n\n\n

The following are examples of important\nsession log file contents.<\/strong><\/p>\n\n\n\n

Typical events include a user input and host reaction:<\/strong>
Date Time <\/code>- <\/code><\/a>getDeviceInput() KEY (#9) keyCode = '720000', thisKey = '[pf3]'
Date Time - processSession() is sending key: '[pf3]' to host.
Date Time - OIANotifyEvent: Event being processed now.
Date Time - refreshOIALine: running...
Date Time - refreshOIALine: 5250 Session is Inhibited.
Date Time - refreshOIALine: completed.
Date Time - -------------------------------------------
Date Time - OIANotifyEvent: Event being processed now.
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for full screen update
Date Time - displayCurrentScreen: From 1 to 1920, Size 1921, Cursor Pos 12,1
Date Time - displayCurrentScreen: Processing Standard Full Screen Update
Date Time - sendEntireScreenToDevice: running...
Date Time - displayCurrentScreen: Completed.
Date Time - refreshOIALine: running...
Date Time - refreshOIALine: 5250 Session is not Inhibited.
Date Time - refreshOIALine: completed.<\/code><\/p>\n\n\n\n

In this example, you can use the user\npressed the function 3 key, which set caused the host to paint new information\nto the screen. This presentation events shows the amount of data painted to the\nscreen and current cursor position. The timestamps of this log can help\ndemonstrate the timing between input and response, since the input received at\nthe server no longer includes network delays.<\/p>\n\n\n\n

Different input types can appear in this log:<\/strong>
Date Time - getDeviceInput() KEY (#7) keyCode = '0D0D00', thisKey = '[enter]'
Date Time - getDeviceInput() SCAN (#27) barType = 0, scanData = 'Q02748277'<\/code><\/p>\n\n\n\n

Key codes are referenced in the StayLinked keyboard map. Barcodes show the barcode symbology type and barcode contents. While the handler log records the data coming from the client, this log shows the data after StayLinked processing. This means that any barcode adjustments by StayLinked will show in this log, but not in the handler log. The following is a list of the different barcode symbology types recognized by StayLinked in the Session log (in the Handler log they will be hex):<\/p>\n\n\n\n

1D Symbologies<\/strong><\/td>2D Symbologies<\/strong><\/td>Other Types<\/strong><\/td><\/tr>
8 = \"MSI\/Plessey\"<\/td>128 = \"PDF417\"<\/td>252 = \"Scale Data\"<\/td><\/tr>
9 = \"Alpha Plessey\"<\/td>129 = \"MicroPDF417\"<\/td>253 = \"Mag Stripe\"<\/td><\/tr>
10 = \"ISBN Plessey\"<\/td>130 = \"MacroPDF417\"<\/td>254 = \"RFID\"<\/td><\/tr>
11 = \"Pure Plessey\"<\/td>131 = \"MacroMicroPDF417\"<\/td>0 = \"Unknown\/Unsupported\"<\/td><\/tr>
12 = \"Sains. Plessey\"<\/td>132 = \"MaxiCode\"<\/td><\/td><\/tr>
15 = \"UCC\/EAN 128\"<\/td>133 = \"Data Matrix\"<\/td><\/td><\/tr>
16 = \"UPC A\/E\"<\/td>134 = \"QR Code\"<\/td><\/td><\/tr>
17 = \"EAN 8\/13\"<\/td>135 = \"Micro QR Code\"<\/td><\/td><\/tr>
18 = \"UPC\/EAN\"<\/td>136 = \"Aztec Code\"<\/td><\/td><\/tr>
32 = \"Codabar\"<\/td>137 = \"Multi-Dimensional\"<\/td><\/td><\/tr>
40 = \"Code 3 of 9\"<\/td>138 = \"Code 32\"<\/td><\/td><\/tr>
41 = \"Trioptic 39\"<\/td>139 = \"Imager\"<\/td><\/td><\/tr>
48 = \"All Code 2 of 5\"<\/td>140= \"Signature\"<\/td><\/td><\/tr>
49 = \"Discrete 2 of 5\"<\/td>141 = \"Web Code\"<\/td><\/td><\/tr>
50 = \"Inter. 2 of 5\"<\/td>142 = \"Cue Code\"<\/td><\/td><\/tr>
51 = \"Indus. 2 of 5\"<\/td>143 = \"Composite AB\"<\/td><\/td><\/tr>
52 = \"Matrix 2 of 5\"<\/td>144 = \"Composite C\" <\/td><\/td><\/tr>
53 = \"IATA 2 of 5\"<\/td>145 = \"TLC 39\"<\/td><\/td><\/tr>
56 = \"Code 11\"<\/td>146 = \"USPost Net\"<\/td><\/td><\/tr>
64 = \"Code 128\"<\/td>147 = \"US Planet\"<\/td><\/td><\/tr>
76 = \"RSS-14\"<\/td>148 = \"UK Postal\"<\/td><\/td><\/tr>
77 = \"RSS-14 Limited\"<\/td>149 = \"Japan Postal\"<\/td><\/td><\/tr>
78 = \"RSS-14 Expanded\"<\/td>150 = \"Australian Postal\"<\/td><\/td><\/tr>
80 = \"Code 93\"<\/td>151 = \"Dutch Postal\"<\/td><\/td><\/tr>
82 = \"Code 49\"<\/td>152 = \"Canada Postal\"<\/td><\/td><\/tr>
88 = \"AMES Code\"<\/td>153 = \"Chinese 2 of 5\"<\/td><\/td><\/tr>
<\/td>154 = \"Bookland\"<\/td><\/td><\/tr>
<\/td>155 = \"Coupon\"<\/td><\/td><\/tr>
<\/td>156 = \"Korean 3 of 5\"<\/td><\/td><\/tr>
<\/td>157 = \"US4 State\"<\/td><\/td><\/tr>
<\/td>158 = \"US4 State FICS\"<\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Some applications paint screen events even when the user is inactive:<\/strong>
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for multi-line update
Date Time - displayCurrentScreen: From 1121 to 1280, Size 1921, Cursor Pos 16,12
Date Time - sendScreenLinesToDevice: running...
Date Time - displayCurrentScreen: Completed.
Date Time - -------------------------------------------
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for full screen update
Date Time - displayCurrentScreen: From 1 to 1920, Size 1921, Cursor Pos 16,12
Date Time - displayCurrentScreen: Detected Empty Screen Update
Date Time - displayCurrentScreen: Completed.
Date Time - -------------------------------------------
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for full screen update
Date Time - displayCurrentScreen: From 1 to 1920, Size 1921, Cursor Pos 16,12
Date Time - displayCurrentScreen: Processing post Empty Screen Full Screen Update
Date Time - sendEntireScreenToDevice: running...
Date Time - displayCurrentScreen: Completed.<\/code><\/p>\n\n\n\n

In this example, the telnet host\nis sending repeated presentation events to the device. This example has a host\nthat repaints the telnet screen every second. This unnecessary traffic\nsignificantly increases the amount of data passed between the telnet client and\nhost. This behavior is most often seen in applications with a clock or timer\nthat updates on a regular interval in the emulation space.<\/p>\n\n\n\n

Application screens drive screen recognition features, which are recorded in the session log:<\/strong>
Date Time - recognitionProcess: no recognized screen found
Date Time - recognitionProcess: ***** Recognized screen 'login' out of 13 screens *****
Date Time - recognitionProcess: Screen recognition instance #1, Host Event, Show this = true
Date Time - recognitionProcessHostAPI: Processing Update User Name = 'jmasters'<\/code><\/p>\n\n\n\n

Handler<\/h2>\n\n\n\n

Default state:<\/strong> Disabled, enabled in server settings for session, handler and socket logging.
Maximum size:<\/strong> Per Server Settings
Cleanup:<\/strong> Deleted and restarted after reaching max size
History:<\/strong> None (see section\n1.4 for snapshot)<\/p>\n\n\n\n

Shows the handling of the session by SL, and includes all inbound inputs\nand outbound presentation events. Since this log is StayLinked Client to\nStayLinked Server, the inputs will show as they came from the device and will\nnot show any adjustment by the server process.<\/p>\n\n\n\n

Minor adjustments have been made to the following example for readability and demonstration. Note that some events have improved logging starting in version 15.1 build 208 of the Server to include additional event recording.<\/p>\n\n\n\n

The following are examples of important\nhandler log file contents.<\/strong><\/p>\n\n\n\n

The session and connection information is recorded when a session is started:<\/strong>
Date Time **********
Date Time StayLinked Handler Starting Session 66407 for 10.10.225.187<\/code><\/p>\n\n\n\n


If a fixed port range is configured for your connections, the port and range is recorded:<\/strong>
Attempting to open a socket on IP 192.168.100.12 on a UDP port between 5000 and 6000
StayLinked Handler is using socket on IP: 192.168.100.12 Port: 5005<\/code><\/p>\n\n\n\n

Once the standard handshake completes, the device returns the \u2018getdeviceconfig\u2019:<\/strong>
Date Time esp_GetDeviceConfig() returns 'AB~001~19~000~MC9190C_E5~14~22~12~01~0130~0000 ~000~002368E6EAFE~640~6007~3~20170406092835~S~WindowsCE      ~2~01~3~0~'<\/code><\/p>\n\n\n\n

More information on the\nclient-server handshake can be found in the Err:Host Timeout and Client-Server\nConnectivity technical references.<\/p>\n\n\n\n

Once the device has been identified, StayLinked processes several advanced features:<\/strong>
Date Time SEND: (0006) 'AA~007~14~00~02~0018~Client Settings...~'
Date Time SEND: (0007) 'AA~008~14~00~03~0020~Device Management...~'
Date Time SEND: (000B) 'AA~012~14~00~04~0018~Client Software...~'
Date Time SEND: (000C) 'AA~013~14~00~05~0015~Provisioning...~'<\/code><\/p>\n\n\n\n

Note the outbound screen update\npacket sequence numbers in parenthesis. These values are in hexadecimal and are\nrecorded for all inbound and outbound packets. These are how StayLinked\nguarantees packet delivery and synchronization.<\/p>\n\n\n\n

The device is then placed into a device group:<\/strong>
Date Time EspLinkDeviceLoader configureDevice Selecting Best Device Group<\/code><\/p>\n\n\n\n

Typical Input Types<\/h3>\n\n\n\n

There are five types of user inputs:<\/strong>
Keyboard \u2013 On-screen or hardware keyboard, transmits the 6-character key code-
Date Time esp_ProcessDeviceInput() - RECV: (seq#) 'AC~343400~Y~'<\/code>
Scan \u2013 Input strings from a scan engine or Android label. NOTE: the second value is the barcode type in hex (e.g. 40 is 0x40, which is decimal 64 or Code 128 in the table above)
Date Time esp_ProcessDeviceInput() - RECV: (seq#) 'AD~40~0~11~A2203000104~\u00a7~'<\/code>
Tap \u2013 touch screen or mouse input that does not hit an on-screen button
Date Time  esp_ProcessDeviceInput() - RECV: (seq#) 'AG~08~0D~'
<\/code>Voice \u2013 Data converted to an input string by Vangard Voice
Date Time esp_ProcessDeviceInput() - RECV: (seq#) 'AI~015~Your Voice Data~'<\/code>
Mnemonic Command \u2013 touch input on a graphical button
Date Time<\/code> esp_ProcessDeviceInput() - RECV: (seq#) 'AH~10~nyc[enter]~'<\/code><\/p>\n\n\n\n

Note the device input string starts with characters that represent the input type following the sequence number of the input by the user in parenthesis. In these examples, AC is a keyboard input which will always include a six-digit key code while AD is a scanned barcode that includes data for the barcode type (in hex) and length. Tap inputs are recorded as AG transactions or AH depending on what was tapped on the device screen.<\/p>\n\n\n\n

Outbound transactions to the device screen appear as a screen print. These SEND packets are sequenced for delivery and include information about the position of the update and update contents.
Date Time esp_XYPrintC()<\/code>
Date Time SEND: (0039) 'AA~058~28~09~10~0005~\u00fb\u00f9\u00f84~09~10~1~'<\/code><\/p>\n\n\n\n

Inputs without a host reaction are common when the host does not paint screen updates. These can be hidden fields, such as a password or when the host does not echo the input back to the user.<\/p>\n\n\n\n

Log Analysis Tool <\/h3>\n\n\n\n

When a StayLinkedHandler log file is opened in the view, the file menu will include the option to analyze the file for you. This takes the standard file and reformats it into a more easily read version. This analysis log will be stored to the Administrator\u2019s local logs directory as mentioned above. The StayLinked Server does not get a copy of the file since it is generated by the StayLinked Administrator. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

The analysis log takes the inputs\nand reactions from the handler log and formats them into a recreation of the\ndevice screens. This usually allows for a simple view of a screen, user input\nand then the reaction screen.<\/p>\n\n\n\n

When the analysis program runs, it\nreads through the file assuming 24×80 rows and columns until the screen\ndimensions are found. Once the client screen size if found in the file, screens\nare formatted knowing the proper display size. If a file does not contain a\nconnection request, it may not be able to format the screen in the proper\nscreen dimensions.<\/p>\n\n\n\n

Starting in Server\/Administrator version 15.5, any Handler log can be run through the analysis tool as an option from the Logs Menu in the Administrator. This replaces the standalone tool that has been included in the Administrator installation folder. The integrated Administrator analysis tool offers a wider range or features and recognition of events that will not be included in the standalone tool that has been deprecated.<\/p>\n\n\n\n

While timestamps are removed from these examples, it should be noted that the timestamps can be an important part of diagnostics efforts. Excessive delays between the user input and host response will directly impact the user experience.<\/p>\n\n\n\n

The following is an example of the analysis log file with comments.<\/strong><\/p>\n\n\n\n

The user is presented with a menu:<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The user pressed a 6 on the device, generating the key code 363600:<\/strong>
Date Time USER PRESSED KEYCODE: 363600 '6'<\/code><\/p>\n\n\n\n

The host updates the selection field with the user input:<\/strong>
Date Time SCREEN UPDATE at Row 12, Col 1, Cursor at Row 12, Col 1 with Length 5, Data '\u00fb\u00f9\u00f86'<\/code><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The host then paints a new screen based on the menu item:<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The user then scans a barcode which is parsed across two fields:<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The host responds by entering the data in the fields:<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The user presses enter:<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The host processes the input and responds with a beep and an error message:<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Socket<\/h2>\n\n\n\n

Default state:<\/strong> Disabled, enabled in server settings for socket logging.
Maximum size:<\/strong> Per Server Settings
Cleanup:<\/strong> Deleted and restarted after reaching max size
History:<\/strong> None (see section\n1.4 for snapshot)<\/p>\n\n\n\n

Also known as the IP Traffic log, this file shows synchronizations, packet payloads and sequence numbers. While not often required, this log shows the reliability of the Client2Host protocol by detailing each inbound and outbound transaction between the StayLinked Client and Server.<\/p>\n\n\n\n

The following is a few examples of socket log contents.<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Note the SYNC-OK message, which\nconfirms that the client and server have confirmed that they are on the same\nsequence numbers and are fully synchronized.<\/p>\n\n\n\n

Several abbreviations are used. These represent server and client sequence numbers. For example,  Last Observed Client Sequence (LOCS) and Last Observed Server Sequence (LOSS).<\/p>\n\n\n\n

Instructional Video: Turn on Session Specific Socket Logging<\/h4>\n\n\n\n