End-of-session indication

[GoogleCodeExporter]

Is it possible to determine on the receiver side if a session has ended (i.e., 
sending app closed the socket or the session timed out)?
I see that PGM_IO_STATUS_FIN is defined but not used in the implementation.

What version of the product are you using? On what operating system?

libpgm-5-1-118

Original issue reported on code.google.com by astov...@gmail.com on 19 Apr 2012 at 3:20

[GoogleCodeExporter]

The STATUS-FIN is for end of broadcast indication.  An example would be the end 
of a video broadcast.  It needs to be explicitly sent by the publisher and the 
publisher needs to remain on the PGM socket until the recovery window has 
elapsed for all receivers.

Therefore a closed socket or timeout appears exactly the same as data loss.  
The solution is to implement a protocol layer above PGM that implements 
notifications of socket closes, heartbeats for session longevity, etc.

Original comment by fnjo...@gmail.com on 19 Apr 2012 at 11:24

• Changed state: WontFix

[GoogleCodeExporter]

Does it mean that pgm_recv() will return PGM_IO_STATUS_RESET if peer timeout 
(set with PGM_PEER_EXPIRY) occurs or the sender closes its socket?

Original comment by astov...@gmail.com on 19 Apr 2012 at 1:16

[GoogleCodeExporter]

Pretty much, both a socket close and a network fault will appear as an 
expiration of some sort.  If no data is being published it will be a peer 
expiry, it is quite possible that the PGM recovery system will fail on request 
attempts leading to the same conclusion.

Unless you can think of some other solution, or can find something in the PGM 
RFC that would be appropriate.

Original comment by fnjo...@gmail.com on 19 Apr 2012 at 1:20

[GoogleCodeExporter]

Hmm.. In my test I am not getting PGM_IO_STATUS_RESET when I kill my sender. 
PGM_PEER_EXPIRY is set to 10 seconds on the receiver side. I am using the 
pgmsend and pgmrecv (with additional PGM_IO_STATUS_RESET case) that come with 
the package. Any ideas?

Original comment by astov...@gmail.com on 19 Apr 2012 at 1:24

[GoogleCodeExporter]

It will need further investigation.  Remember a PGM socket can have multiple 
publishers.  Due to 'location transparency' the protocol doesn't really provide 
notifications of connections and disconnections.  Some implementations such as 
Talarian's SmartPGM handle 'connections' per sender as rigid separate entities 
that must be manually acknowledged.

I understand the requirement but there is also the complexity of how to return 
the status.  A 'peer timeout' or similar return method to pgm_recv or some 
separate messaging queue?

Original comment by fnjo...@gmail.com on 19 Apr 2012 at 2:35

[GoogleCodeExporter]

It would be helpful for some (most?) applications if PGM provided some 
indication of whether a session is still active or not. Why duplicate the 
heartbeat mechanism in an app if it already exists in PGM?
As for returning the status, I think a 'peer timeout' status code returned from 
pgm_recv would be appropriate.

Original comment by astov...@gmail.com on 20 Apr 2012 at 1:11

[GoogleCodeExporter]

Do you think it would be reasonable to add this 'peer timeout' status code? If 
yes, do you think you could add it in the next release?

Original comment by astov...@gmail.com on 26 Apr 2012 at 10:19