server-sdk-go: first PublishData always results in an error
Hi!
Thx for your great work with livekit. It’s a really awesome framework and very easy to use!
However I’m getting an error when sending some data
room.Callback.OnParticipantConnected = func(p *lksdk.RemoteParticipant) {
if err := room.LocalParticipant.PublishData([]byte("hello"), livekit.DataPacket_RELIABLE, []string{p.SID()}); err != nil {
log.Printf("could not publish data to participant '%s', err: '%v'", p.SID(), err)
}
}
After a few SECONDS this call results in the error
could not publish data to participant 'PA_kCS2E6r2YV3c', err: 'could not connect after timeout'
Immediately after that log entry, the following log entry occurs:
"level"=0 "msg"="successfully set publisher answer"
After that log entry I’m able to successfully send data messages. It seems to me that the first call to PublishData blocks some logic.
If I try to send with a go routine like this
room.Callback.OnParticipantConnected = func(p *lksdk.RemoteParticipant) {
log.Printf("OnParticipantConnected '%s'", p.Identity())
go func() {
time.Sleep(time.Second * 1)
sendData(p)
time.Sleep(time.Second * 1)
sendData(p)
}()
}
the first send results in the error
could not publish data to participant 'PA_73nWKR3avB7X', err: 'io: read/write on closed pipe'
the second send succeeds.
In conclusion: the first PublishData always fails. Afterwards it works.
I’m not sure if it matters but the other participant is using the js-sdk
Any help would be greatly appreciated 😄
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 16 (16 by maintainers)
@davidzhao yeah it’s a data channel timing issue, unrelated to the reconnect issue @qwertzui11 Thanks for your narrow down, I found the root cause is timing issue of subscriber data channel open and publish data send. The participantConnected callback fired not means remote participant’s subscribe data channel is open, so the data may lost. Sequence:
That’s why subscriber can get data when it first join, and lost data if reconnect. Will draft a PR to fix this
@qwertzui11 thank you for the repro
I’m able to reproduce this as well… It’s not clear to me why it’s happening though. there seems to be some leftover state here.
It seems unrelated to the issue linked above.
It is some work about sdk parts to improve, probably need to expose data channel state to users