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.

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;

}

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 ?

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.

6.

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.

Hi @zoya.farberov or @Warat B.,

Can I get a response for this question ?

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?

Hi @zoya.farberov,

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.

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.

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.

Hi @zoya.farberov,

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 ?

Any updates on this ?

Hi @zoya.farberov,

Any updates on this ?

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.