This seems to be a quite common issue with Simple-peer. I have simple video chat app which connects 2 peers using WebRTC, Socket.io and Simple-peer.
When I peer 1 calls Peer 2 for the first time, everything is fine. Same with 2nd call (so reconnection isn't an issue) but the 3rd time it throws an error
Uncaught Error: cannot signal after peer is destroyed
I'm not destroying the peer in my code either end i.e. no peer.destroy() being called either end.
My question is, if there are 2 users logged into the app. can they stay logged in and call each other repeatedly without having to refresh/reload the app?
Or is the Socket.id that's issued to each new user that needs refreshing before each call?
In other terms -- If 2 peers made a connection, had a video call and ended the call. Is there a way to reconstruct the peer object between the same 2 peers for a new call without refreshing/reloading the app?
Many thanks in advance. Sorry I haven't included the code because I thought its more of a concept question.
Related
I see something like the following error while using azure event hub to send event message. But as I see in the azure portal, the metric shows that the event message is sent to the event hub. So I'm puzzled by what this error message means.
As I read from the azure doc (https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-amqp-troubleshoot), it said "You see the following error on the AMQP connection when all links in the connection have been closed because there was no activity (idle) and a new link hasn't been created in 5 minutes."
The doc also said "You can avoid them by making send/receive calls on the connection/link, which automatically recreates the connection/link."
What should be done regarding this error message ? As although the event message can be sent, I worry whether there may be any potential issue there.
" Error{condition=amqp:connection:forced, description='The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:00000000000000000000000000000000000_G21, SystemTracker:gateway5, Timestamp:2019-03-06T17:32:00', info=null} "
I once tried that if I call the close() method in EventHubProducerClient (by refer to sample code in https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-java-get-started-send), this error seems not appear again. However, if doing so, when every time need to send the event, it will mean need to create a new EventHubProducerClient. I'm not sure if this may create another problem (like time required to create the new EventHubProducerClient, and memory consumption) if creating a new EventHubProducerClient for every send event, as there can be many events to send.
On another search, I found in How to configure Producer.close() in Eventhub, that it is recommended to close the producer client after using it.
However, if the above error message is actually not an error, whether to close or not may not matter.
I'm building an application where I need to manage the drop-off screen, ie, the screen from where the user killed the application.
One way to solving this problem is to ask the JS client to send an event to the server. The event will be the last successfully executed screen. For eg:- if my application has 10 different screens, then the last screen which was successfully completed by the user, the client will send the server the screen_name.
Now when the client wants to know the screen from where the user dropped-off, it can make a GET call and fetch the same.
The cons I see with this solution is:-
1) Dependency on the client for sending an event. If while sending the event, the connection drops-off or the user killed the application(website), then the client has no way to send the event again. In this way, the user will come back again to the same screen which was successfully completed
2) Increased number of network calls.
Is there any way in which server can itself handle the drop-off state? I have RESTful APIs.
I am streaming a tty's stdout and stderr to RabbitMQ (logs to be exact). These logs can be viewed on a website and while the content is streamed to RabbitMQ they are consumed by the webserver and forwarded to the client using WebSockets. Logs are immediately persisted after sending it to RabbitMQ.
When the user accesses the website the persisted logs are rendered and the consecutive parts are streamed using WebSockets. The problem is that there is a race condition as the persisted logs might be missing chunks of the log that occurred between rendering the site and receiving the first chunk via WebSocket.
My idea was to keep all chunks in the queue and send those via the WebSocket after connecting. Additionally I would add a worker to listen to some kind of a "finished" event which then takes everything in the queue and persists it at once.
The problem is that I don't know if this is possible using RabbitMQ or how. Any ideas or other solutions?
I don't think it really matters but my stack is using Ruby Sinatra and the Bunny RabbitMQ client.
While I agree with your general idea about picking up where you left off, after loading the intial page, what you're trying to do isn't something that should be done from RabbitMQ.
There are a lot of potential problems that this would cause, which I've outlined in a blog post, previously.
Instead of trying to do this w/ RMQ, I would do this from a database layer.
As you push things into the database, you have an ID - hopefully one that is sequential. If not, add a sequence to the entries.
When you load the page for the user, send the current ID that they are at down to the browser.
After the page finishes loading and you're setting up the websocket connection, send the user's current spot in the list of messages via the websocket. then the websocket connection can use that id to say "give me all the messages after this id, and start streaming them"
Again, this is not done via RabbitMQ (see my article on why this is a bad idea), but via your database and sequential IDs.
I have multiple senders connecting to my receiver simultaneously via Chrome. When one of the senders disconnects (closes browser window, refreshes the page, loses connection... etc) I want the "onSenderDisconnected" event to fire on the receiver.
So far, this only seems to happen when connection is lost for whatever reason. If the sender simply refreshes, for example, the sender is never dropped and a new sender is created. That means I might have 2 senders "connected" from the same source.
Is there any way I can either drop the old sender when one reconnects or is there a way to keep the same senderID on reconnect?
I also want to give each sender the option of disconnecting from the session manually (with a button). The only way to do this currently is to stop casting to the device, but that ends the session for all users. How might I go about this?
For the first issue, I am handling it by keeping track of my "Senders" manually.
Each sender has an "id". Something like 2:client:23522. The first number before the colon (2) seems to stay the same no matter how many times that specific client reconnects to the session. The 2nd number (23522) changes each time.
By checking the first number of a connecting client you can determine whether it is a new client or an existing client that reconnected. That way, when sending messages back and forth between the client/sender you can keep an array of the "active" clients and forget about the old unused client id's.
For the first item (i.e. adding more senders upon each reload), I have opened an internal issue to investigate that. For the second one, currently you cannot just disconnect your chrome sender without stopping the application; you can either (a) Stop application + disconnect (if you use the cast extension) or (b) close the tab which is like "nothing has happened". We are considering bringing that closer to the APIs on the other two platforms.
I'm pretty new to MSMQ 4.0. I got stuck with below scenario;
Service A takes User Details and Returns an User ID.
Then Service B takes Billing detials with User ID.
Now I have to Queue these steps. I'm planning to use Transaction Queue.
Could some one please help me with
1)Get the ID from first message and include it in the second message.
2)If at least one step failed I have to rollback(transaction Queue does it for me) retry or 5 times and if it still failed then move it to VerifyAdminQueue for verification by Admin.I dont like using DeadLetter Queue etc.,
Thanks in advance.
Services built with MSMQ queues are truly one-way. This means that there is no built in concept of a response. There are many ways you can implement a request-response communication pattern using MSMQ but with all of them you will need to construct and send the response back to the caller yourself.
With one way actions, rollback is very simple, and indeed MSMQ will rollback any failed steps in the transmission of a message. More complex operations such as request-response however lack any concept of a transaction in MSMQ and so any rollback across more than one message transmission steps will require you to write compensatory code.