Message delay from rsslWrite to the wire

Susan Genoray

There appears to be a delay from when client login responses are passed to the “rsslWrite” function to appearing on the wire:

1. Client connects to ASG from RMDSTestClient -> EED -> ASG RR, and sets up a private stream connection.
2. A TS request is sent from RMDSTestClient which will result in many responses being returned by ASG
3. Once UPAComms in ASG RR starts sending responses, the connection is closed from the RMDSTestClient which the re-establishes the connection immediately after
4. A client login request message is sent to ASG RR and then the response is passed to “rsslWrite” function, and at this point there can be a delay of up to 40 seconds before this appears in the pcap file.

Bondy_Bo

Ensure that you are using rsslWrite and rsslFlush in the correct manner. By design, rsslWrite does not guarantee content is pushed out to the wire. For efficiency on the wire and reduced overhead due to system calls, this method will queue content. rsslFlush will take queued content and try to do bulk writes to the network with as much queued content as possible.

The return values from both rsslWrite and rsslFlush indicate how many bytes remain queued. I suspect that you are not calling rsslFlush and then the first time you call rsslPing this is resulting in your content being pushed out to the wire. rsslPing will either send a ping message if no content is queued or it will invoke a call to rsslFlush if any content is queued.

This is documented in the UPA Developers Guide Chapter 12: Reliable Transport Package Detailed View. Section 12.7 talks about writing data, which covers all of the outbound methods rsslWrite, rsslFlush, rsslGetBuffer, rsslReleaseBuffer, rsslPing) and it has code samples in the document to illustrate all of the information. Additionally, the UPA examples also show this functionality in action.