Handling of ETA API status

I'm using ETA C API in Linux and have the following questions on handling these scenarios

1.What
is the recommended action that client need to take if rsslRead() returns the
following errors ? Currently, we disconnect and reconnect to recover
connection.

RSSL_RET_CONGESTION_DETECTED

RSSL_RET_SLOW_READER

RSSL_RET_PACKET_GAP_DETECTED

2.Under
Login status: RSSL_MC_REFRESH and RSSL_MC_STATUS:

a.When
does the client receive the errors: CLOSED, CLOSED_RECOVER for login
request ? Currently, the application recovers connection.

b.When
does the client receive error SUSPECT for login request ? Currently, the
application closes source directory stream and doesn’t recover connection.
Should it disconnect and reconnect to recover connection ?

3.For
Login status RSSL_MC_UPDATE, application takes no action

4.For
login status RSSL_MC_CLOSE, application recovers connection.

Source directory Messages

5.When
does the client receive message from ADS with the states: RSSL_MC_UPDATE,
RSSL_MC_CLOSE and RSSL_MC_STATUS ? Currently, the application takes no action.

6.How
does the client application notified if a particular service is down or up ?
What does the application need to do to recover ?

Dictionary Messages

7.How
does the update to dictionaries sent to client ? This is not shown in examples
?

8.What
does the message RSSL_MC_STATUS mean ?

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

Accepted answers

warat.boonyanit

Hi @RAJ
1. These three rsslRead Return Codes are for multicast connection. If you are not using UDP-based multicast connection, then you don't have to worry about it.

The Return Codes means a gap was detected in the inbound transport content and the application should perform item recovery it may be able to do on a non-multicast connection.

2.a Login stream state RSSL_STREAM_CLOSED and RSSL_STREAM_CLOSED_RECOVER are used when rejecting login.

RSSL_STREAM_CLOSED is used when the client should not attempt another login with the same credential, e.g. invalid username.

RSSL_STREAM_CLOSED_RECOVER is used when the client can attempt another login with the same credential at a later time.

The application doesn't have to recover the connection. It should show the statusText of the login status so that the user know why their login was rejected.

2.b The dataState = RSSL_DATA_SUSPECT is part of the above login reject. It has no special meaning in login request-response. Check the above answer.

3. RSSL_MC_UPDATE is not used in login stream.

4. Login RSSL_MC_CLOSE is used by client/consumer applications. It is a logout message. Client/consumer applications should never receive this message from server.

Basically:

RSSL_MC_STATUS + RSSL_STREAM_CLOSED or RSSL_STREAM_CLOSED_RECOVER is login reject. Sent from the server.

RSSL_MC_CLOSE is logout. The client sent to logout.

5. RSSL_MC_UPDATE - This message conveys service UP/DOWN and item group status information.

RSSL_MC_CLOSE - Never. It is not used in directory stream.

RSSL_MC_STATUS - This message conveys state change on directory stream. In reality, it uses when the server kicks the client out. The client can receive this message along with the login reject, so it can ignore this one and process login reject.

6. From RSSL_MC_UPDATE. The server will send directory update message with State Filter Entry.

The entry will have ServiceState and AcceptingRequests elements.

ServiceState means, well, service state. Service down means this service cannot provide current data. However, the service can still accept item requests if AcceptingRequests is true.

7. The consumer will receive RSSL_MC_STATUS with state of RSSL_STREAM_OPEN/RSSL_DATA_SUSPECT, indicating dictionary version change. It may then reissue its dictionary request to obtain the latest version.

8. See above.

All comments

warat.boonyanit

Hi @RAJ
1. These three rsslRead Return Codes are for multicast connection. If you are not using UDP-based multicast connection, then you don't have to worry about it.

The Return Codes means a gap was detected in the inbound transport content and the application should perform item recovery it may be able to do on a non-multicast connection.

2.a Login stream state RSSL_STREAM_CLOSED and RSSL_STREAM_CLOSED_RECOVER are used when rejecting login.

RSSL_STREAM_CLOSED is used when the client should not attempt another login with the same credential, e.g. invalid username.

RSSL_STREAM_CLOSED_RECOVER is used when the client can attempt another login with the same credential at a later time.

The application doesn't have to recover the connection. It should show the statusText of the login status so that the user know why their login was rejected.

2.b The dataState = RSSL_DATA_SUSPECT is part of the above login reject. It has no special meaning in login request-response. Check the above answer.

3. RSSL_MC_UPDATE is not used in login stream.

4. Login RSSL_MC_CLOSE is used by client/consumer applications. It is a logout message. Client/consumer applications should never receive this message from server.

Basically:

RSSL_MC_STATUS + RSSL_STREAM_CLOSED or RSSL_STREAM_CLOSED_RECOVER is login reject. Sent from the server.

RSSL_MC_CLOSE is logout. The client sent to logout.

5. RSSL_MC_UPDATE - This message conveys service UP/DOWN and item group status information.

RSSL_MC_CLOSE - Never. It is not used in directory stream.

6. From RSSL_MC_UPDATE. The server will send directory update message with State Filter Entry.

The entry will have ServiceState and AcceptingRequests elements.

ServiceState means, well, service state. Service down means this service cannot provide current data. However, the service can still accept item requests if AcceptingRequests is true.

8. See above.

RAJ

2b. In the sample program, I see RSSL_DATA_SUSPECT + RSSL_STREAM_OPEN
is used to detect suspect state as below. It seems like it is different from CLOSED
and CLOSED_RECOVER.

else if
(pState->streamState == RSSL_STREAM_OPEN && pState->dataState ==
RSSL_DATA_SUSPECT)

{

printf("\nLogin
stream is suspect\n");

isSuspect
= RSSL_TRUE;

return
RSSL_RET_FAILURE;

}

6. Would the service down message invalidate all the open subscription in that connection.

7. If the dictionary update happens, would you recommend the client application to close existing subscription and re-open all subscriptions since the field definition of the fields that client used might have changed ?

How likely would this happen ?

zoya faberov

Hello @RAJ

2b. Please refer to the previous responses, detecting and recovering connection when receiving CLOSED and CLOSED_RECOVER on login request is correct. DATA_SUSPECT is part of login reject, but if it's on login, no additional processing is required. (DATA_SUSPECT is important on an item stream).

6. Yes, in that the items streams from the service that is down will not be "healthy" or updating. And the opened items will reflect that state, should become SUSPECT. If there is more then one infra component providing the same service, it can be alternatively consumed from the other infra component that has this service.

7. The dictionary update does not happen often, and usually it impacts very few fids. But from these few, there may be one or more that your application is consuming, so one can never be too careful.

Your market data admin or group is likely to inform you of the update to the infrastructure that will entail the dictionary change.

So as an application designer you can choose to handle it in the application, by re-subscribing to dictionary and re-subscribing any open items. Or can choose to handle procedurally, by mandating the application restart following the update, which is usually run by market data admins over the weekend.

RAJ

Can you point me to a code snippet that shows how to check for the service up/down message when RSSL_MC_UPDATE is received in the source directory response ?

I don't see any relevant information in the following page.

RAJ

Hi @zoya faberov or @warat.boonyanit,

Can I get a response for this question ?

zoya faberov

Hi @RAJ,

Please find in Elektron SDK example VAConsumer

Elektron-SDK1.2.0.win.rrg\Cpp-C\Eta\Applications\Examples\VAConsumer

In it please review rsslDirecotryHandler code:

...
case RDM_DR_MT_UPDATE:
		printf("\nReceived Source Directory Update\n");
		pUpdate = &pDirectoryMsg->update;
...

if (pService->flags & RDM_SVCF_HAS_STATE)
{
	printf("\tService State: %s\n", pService->state.serviceState == 1 ? "Up" : "Down");
	pCommand->isServiceReady = 
	pService->state.serviceState == 1 && 
	(!(pService->state.flags & RDM_SVC_STF_HAS_ACCEPTING_REQS) || 
	pService->state.acceptingRequests == 1);

...

Is this handling what you are looking for, how to track service state up/down?

RAJ

Hi @zoya faberov,

I use ETA C API and don't have access to the structure included in your response. Can you provide an equivalent code snippet for ETA C API ?

I looked at the updateMsg structure in source directory response (below) and didn't see service state.

zoya faberov

@RAJ,

Apologies, my bad, as I was answering several questions, I confused which follow-up question was for which API.

zoya faberov

@RAJ

I have updated my answer above with the complete path, within my Elektron SDK 1.2 (ETA C) distribution , to the example I was referring to.

RAJ

Hi @zoya.farberov,

As I mentioned in my original post, I'm using ETA C API in Linux and not in Windows. I'm not using Value Added Consumer API. The Elektron-SDK1.0.8.linux/Eta/Applications/Examples/Consumer/rsslDirectoryHandler.c package doesn't have code that shows how to handle service UP/DOWN.

RAJ

Hi @zoya faberov,

As I mentioned in the earlier, we are using ETA C API in Linux and not in Windows. Please refer to the screen capture I have for the source directory update message I received from ETA C API. This structure doesn't show the code snippet you have sent.

zoya faberov

Hello @RAJ,

The same example code definitely exists in ETA C Linux SDK examples, as in Windows.

However, I think I understand where the disconnect comes in. It is part of the Value Add example.

Example path:

Elektron-SDK1.2.0.linux.rrg\Cpp-C\Eta\Applications\Examples\VAConsumer

This handling is part of VA consumer example, file rsslDirectoryHandler.c

If your application requires parsing this info, Value Add would be useful to you.

Hope this helps.

RAJ

Hi @zoya faberov,

I don't use value added code that uses reactor, so I don't have access to the same data structure as shown below:

From value add rsslDirectoryHandler.c:

directoryMsgCallback(RsslReactor *pReactor,
RsslReactorChannel *pChannel, RsslRDMDirectoryMsgEvent *pDirectoryMsgEvent)

From Non-value add rsslDirectoryHandler.c:

processSourceDirectoryResponse(RsslChannel* chnl, RsslMsg*
msg, RsslDecodeIterator* dIter)

I am not planning to use VA reactor code to identify service up/down message. Can you send me the code-snippet to use the raw ETA API to identify service up/down message ?

RAJ

Any updates on this ?

RAJ

Hi @zoya.farberov,

Any updates on this ?

RAJ

Hi @zoya.farberov,

Any updates on this ?

Jirapongse

You can modify the code in decodeSourceDirectoryResponse function (rsslDirectoryEncodeDecode.c) to decode the directory update message. I have created an example function for your reference called decodeSourceDirectoryUpdate. This function will find the updated service in RsslSourceDirectoryResponseInfo and then update its values. decodesourcedirectoryupdate.txt

You can use this code in processSourceDirectoryResponse in rsslDirectoryHandler.c.

RsslRet processSourceDirectoryResponse(RsslChannel* chnl, RsslMsg* msg, RsslDecodeIterator* dIter)
{
...

switch(msg->msgBase.msgClass)
	{
	case RSSL_MC_REFRESH:
...

	case RSSL_MC_UPDATE:
		if (decodeSourceDirectoryUpdate(&sourceDirectoryResponseInfo[0],
			dIter,
			MAX_SOURCE_DIRECTORY_SERVICES,
			MAX_CAPABILITIES,
			MAX_QOS,
			MAX_DICTIONARIES,
			MAX_LINKS) != RSSL_RET_SUCCESS)
		{
			printf("\ndecodeSourceDirectoryUpdate() failed\n");
			return RSSL_RET_FAILURE;
		}


		printf("\nReceived Source Directory Update\n");


		for (i = 0; i < MAX_SOURCE_DIRECTORY_SERVICES; i++)
		{
			if (strlen(sourceDirectoryResponseInfo[i].ServiceGeneralInfo.ServiceName))
			{
				printf("Received serviceName: %s\n", sourceDirectoryResponseInfo[i].ServiceGeneralInfo.ServiceName);

				printf("service state= %d\n", sourceDirectoryResponseInfo[i].ServiceStateInfo.ServiceState);
				printf("\n");
			}
		}
		break;

After processing the directory update, it will print all service names and statuses on the screen.

Moreover, you can also refer to the ValueAdded code in github at rsslDecodeRDMDirectoryMsg function which shows how to decode the directory update message.

EXPLORE OUR SITES