This is important for developers that use SitePlayer
Whilst developing the Egg-Nunciator and DMX passthru facilities for the WebBrick we started to use larger UDP packets.
We have found a situation that will cause SitePlayer modules to crash. We have logged this bug with NetMedia but it is unlikely to get fixed in the short term.
Our application can generate reasonably high rates of UDP packets, between 1 and 10 per second. Our WebBrick experience has shown us that these rates previously presented no problems.
For clarity the SitePlayer is receiving the UDP packets. The payload of the UDP Packets is delivered to the SitePlayer COM object at hex FF19. The COM object is running at the default 9600 baud. This problem was observed on two production systems and reproduced on a test system. All SitePlayer modules were 'new' i.e. low profile, no serial numbers.
However now that we are driving the definition of DMX scenes over the UDP protocol the packet size has grown larger. We found that the SitePlayer module in our WebBrick would crash after 2 hours or so of sustained use. The payload sizes were 12 and 24 bytes. We determined that the SitePlayer had crashed because it would not communicate on any protocol. The PIC chip within the WebBrick has a heartbeat LED so we could determine that the application on PIC was still functioning.
We think that the key issue is a race condition that exists when the SitePlayer has to process a UDP packet (whose payload is destined for the COM object) whilst accepting data on the RS232 port (i.e. the COM object).
We have discovered that the work-around is to use a UDP PAYLOAD of 4 bytes or less (i.e. not including the addressing or null byte terminators)
Our DMX routines have been updated to break the scenes into 4 byte chunks which are reconstructed within the PIC chip of the WebBrick |