Hi Peter,
The timeout is a “network timeout”, that is, it is a maximum time to communicate with the server, not a maximum time to receive data packets when server communication is established. So I think perhaps your “hang” case is successfully connecting to the server and making a request, but no data is returned because the server does not have data for “WI_ABD:HHE”. So the collect loop continues indefinitely. It seems that a SeedLink server will “accept” a stream selector even if it does not support the stream, perhaps with the idea of supporting dynamically new stations? An example (SeisGram2K in Java) :
[0] parsed 1 streams from stream list
[0] [rtserve.iris.washington.edu:18000] network socket opened
[0] [rtserve.iris.washington.edu:18000] sending: HELLO
[0] [rtserve.iris.washington.edu:18000] connected to: ‘SeedLink v3.1 (2015.188 Ring Server SeedLink) :: SLPROTO:3.1 CAP EXTREPLY NSWILDCARD BATCH’
[0] [rtserve.iris.washington.edu:18000] sending: STATION XXX *
[0] [rtserve.iris.washington.edu:18000] response: station is OK (selected)
[0] [rtserve.iris.washington.edu:18000] sending: SELECT BHZ
[0] [rtserve.iris.washington.edu:18000] response: selector BHZ is OK
[0] [rtserve.iris.washington.edu:18000] response: 1 selector(s) accepted
[0] [rtserve.iris.washington.edu:18000] requesting specified time window
[0] [rtserve.iris.washington.edu:18000] sending: TIME 2015,10,22,13,12,26
[0] [rtserve.iris.washington.edu:18000] response: DATA/FETCH/TIME command is OK
[0] [rtserve.iris.washington.edu:18000] 1 station(s) accepted
[0] [rtserve.iris.washington.edu:18000] sending: END
[0] [rtserve.iris.washington.edu:18000] sending: keepalive request
[0] [rtserve.iris.washington.edu:18000] keepalive packet received
…
I hope this helps some…
Best regards,
Anthony
Hi Anthony
Ok, thanks. So I miss understood the meaning of the network timeout, however the process hangs on trying to read an empty socket which seems odd to me. Surely the seedlink protocol must include a method to inform the client that no data is to be expected so that the client can stop trying to read data from the socket?
Personally I solve this for now by sending an INFO request to the server and filtering away any stream not available at the server prior to requesting data.
However, this requires more data traffic than what would be required if the server simply tells the client that none of the requested streams are supported. The server side can still keep the socket open to support dynamically adding new stations but this gives the client the possibility to decide if to hang in there or bail out.�
regP
Hi Peter,
The DMC's ringserver implementation of SeedLink (as used in Anthony's illustration) accepts all STATION requests for the reason he stated: dynamic streams. For example, a client may use wildcards to select all streams from a network, and then receive new streams when they arrive at the server. In this scenario there is no way for the server to know what stations/streams will ever flow through it. Also, ringserver has a single FIFO buffer and any station/stream that does not deliver data for a while will have all of it's data pushed out of the buffer, after which ringserver has no record of said station/stream. The alternative is for a client to continuously re-negotiate, i.e. re-discover the station/stream list and re-connect to re-submit an updated subscription.
regards,
Chad
First of all sorry if this thread is getting out of the scope of ObsPy.
Hi Chad
So out of curiosity, to what level is a response to the INFO command implemented in the DMC's implementation of seedlink (I understand that this is not necessarily required)?
regP
Hi Peter,
ringserver supports these INFO levels:
ID, CAPABILITIES, STATIONS, STREAMS, CONNECTIONS
Not supported are:
GAPS and ALL
Chad
Hi Chad
So in principle the server have information about which streams it have handled before and (albeit perhaps not supported by the protocol) could inform the client upon connection that none of the requested streams have been handled before, no?
A last question and I will drop this:
Since from now on I intend on using the INFO command to gain the control I wish to have, can I reduce the load on the server somehow by limiting the request (or should I perhaps not worry about this and simply request all INFO at stream level)
regP
Hi Peter,
So in principle the server have information about which streams it have handled before and (albeit perhaps not supported by the protocol) could inform the client upon connection that none of the requested streams have been handled before, no?
The ringserver knows what it has at any given time, it does not remember streams that it handled previously but are no longer in the buffer. But, yes, it knows what it has at the time of the request and could, in theory, match that against the requested stations and tell the client which ones have no match. If I remember correctly, the GEOFON seedlink server behaves as you write above, matching stations and reporting status to the client.
The converse of that logic is that a client can not subscribe to a stream that is not known, seen or pre-configured somehow. The DMC's SeedLink export server has 28,000+ streams and the set changes little by little continuously (stations coming and going). A preconfigured list of streams and/or remembering every channel ever seen (some never to be seen again) are not feasible. Not being able to subscribe to some streams just because a station has been down for a day (and thus not in the buffer) would be poor service. Hopefully this helps illustrate why I implemented ringserver the way it is.
A last question and I will drop this:
Since from now on I intend on using the INFO command to gain the control I wish to have, can I reduce the load on the server somehow by limiting the request (or should I perhaps not worry about this and simply request all INFO at stream level)
I do not know of any way to subset or limit an INFO STREAMS request.
Chad
PS. Just to take this even more off topic. The native network protocol for ringserver, called DataLink, addresses these issues: the response for subscriptions includes the count of currently matched channels and information requests can be limited to a matching set of streams. I only mention this in case someone finds this thread and is looking for a server & protocol to adopt, it will not supplant SeedLink anytime soon (or ever).
Hi Chad, thanks for the very detailed information
Ok Just to make this absolutely clear to me
The content of the reply to the INFO command is what's currently in the ringserver?
I do understand the motivation for accepting subscription to just any stream (and fully agree) I just find it very annoying not getting anything at all and not knowing why (no data available, bug in my code, bug in the server I connected to, what...). But then again I am a controlfreak in some aspects, sorry...
regP
Hi Chad, thanks for the very detailed information
Ok Just to make this absolutely clear to me
The content of the reply to the INFO command is what's currently in the ringserver?
Yes, the ringserver response for INFO STATIONS, STREAMS, and CONNECTIONS requests represents the current state and contents of the buffer.
Chad