I just installed the latest Elementary OS Freya and did all the updates.
anytime I use the terminal as root, I see this warning message:
Failed to open connection to "session" message bus: Did not receive a
reply. Possible causes include: the remote application did not send a
reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.
I read this is because there are two graphical interfaces conflicting, but that's a little confusing as I'm just running the base configuration without any modifications.
anyone has an idea of how to fix this?
Related
I am using websockets to talk with server but I want to prevent client from connecting if a requirement is not met. My code is very simple
let socket = new WebSocket('wss://server.com/server/');
socket.addEventListener('open', function(e) {
// we are now connected
});
How does nodeJS connect? It must send a connect message right? Is there a way to edit that message? I'd like to limit it so connections can not be made unless a key is sent with the connection message.
How it works now I send a "login request message" and if the credentials dont match I terminate the connection but currently people could still open connections without sending the login request. This would be a security issue right? People could just DDOS by creating a bunch of connections without logging in.
It's not NodeJS's responsibility to manage DOS/DDOS requests. That is done at the network layer (routers, switches, load balancers, proxies, etc.). See this answer for more detail: protection agains DOS websocket with ip address
Preventing users from continuing to communicate over the socket can be done after a successful connection is made and then the key sent, after which, if it's marked as valid by the server, it continues, otherwise it closes the connection. The limits on how many times a client can connect (or in this case re-connect) are handled by the network rules.
I have been using EWS exchange version 2015 for my code and it was working until recently, on several occasions, one of the several error messages appear
"The request failed. The remote name could not be resolved: 'outlook.office365.com'"
"The request failed. The remote server returned an error: (401) Unauthorized."
"The request failed. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."
"The request failed. The operation has timed out"
when I am trying to bind to email messages.
Currently the code sometimes work and at other times it doesn't. Just wondering does someone have a solution to this? Or is this just a issue on the office365 server side and I can do nothing about it?
exchangeService = new ExchangeService(ExchangeVersion.Exchange2015);
EmailMessage emailMsg = EmailMessage.Bind(exchangeService, item.Id);
Side Note:
I am absolutely sure that my credentials are correct and the domain name I have entered is correct as its hard coded into my application and I haven't edited it in years. With the same credentials I can log in to outlook.com successfully
"The request failed. The remote name could not be resolved: 'outlook.office365.com'"
Nothing to do with the Service (outside of any well documented outages) this is network connectivity or DNS resolution issue
"The request failed. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."
Yep see this one a fair bit especially if your connection in more latent (I'm in Australia) it means for resilient code that every request for EWS you should wrap in Try Catch and retry at least once (you should also be doing this so you can process any throttling responses). Large attachment uploads can be a bit of pain if you have very low end network connections.
"The request failed. The operation has timed out"
That can be service or the network, usually you would see that on a Search using FindItems. The default timeout in EWS Managed API is 90 seconds so you can adjust that up I've never seen that error on a Bind though so sounds like really poor network connectivity.
"The request failed. The remote server returned an error: (401) Unauthorized."
I would make sure you set the X-AnchorMailbox header as discussed in
https://blogs.msdn.microsoft.com/webdav_101/2018/06/16/best-practices-important-and-critical-headers-for-ews/ . This affect the routing of the request (and its always used by all client such as OWA and Outlook)
A good way of testing would be spin up a VM on Azure somewhere (you can choose different regions to test from) and run your code for a while there and test that against what you see locally to see if the errors correlate.
I'm coding a project which needs cloud control device operation, and want to keep information in sync.
The cloud needs to know the state of device, such as when the network is interrupted and when the network is restored.
When the network is restored, the modified information on the cloud is synchronized to device.
anyone got an idea of how my approach should be like? any tips?
I intend to add resident programs in the background at both ends to determine, but in fact, it is impossible for the cloud in the project to connect only one device, and multiple apps may run in one device, which is very tedious to do. Is there any simple component to realize this function?
I wish control information and data information to be synchronized on the cloud and device
Based on your tag, I'm assuming that you are using MQTT as a messaging protocol for your system. If so, to address your need for tracking the device-cloud connection state, MQTT specifies a feature called "Last Will and Testament".
From the MQTT 3.1.1 Standard Section 3.1.2.5:
If the Will Flag is set to 1 this indicates that, if the Connect request is accepted, a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet [MQTT-3.1.2-8].
This can be leveraged to let the remote MQTT client on the cloud know when the device is connected and when it disconnects by publishing an online payload to a topic (for example) device/conn_status after a successful connection, and registering a Last Will offline message to the same topic. Now, whenever the device client goes offline, the broker will publish the offline payload on his behalf to the cloud client that can now act accordingly.
I am using Bluedroid stack for developiong my bluetooth apllication.
I am using A2DP src profile to make connection between Mobile and my device.
I have issue in following scenario:
When i switch from A2DP SINK profile to A2DP Source profile, the first connection request from Mobile site is always failure.
And after first connection request its always success.
I found the reason for fail is:
AV connection state is changing from
BTAV_CONNECTION_STATE_CONNECTING
...
...
BTAV_CONNECTION_STATE_DISCONNECTED
I have checked the flow in Bluedrod Stack, and found that streamming open is failed and due to this i gets BTAV_CONNECTION_STATE_DISCONNECTED event to my app.
Any help would be appreciated.
For more information please comment.
The fail status is BTA_AV_FAIL_STREAM in bluedroid stack
I got the answer/solution of this problem.
Qualcomm engineer has provided a patch to solve the issue.
Whenever there were switch between A2DP sync to A2DP src profile the SDP records is not set properly due to that the first connection request is rejected.
When the rejection happens on first time it sets the value of A2DP SRC in SDP records properly and due to that further connection request is accepted.
I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.
Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?
It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.
Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.
Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.
In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).
Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.
webSocket network view in Chrome Debugger
The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.