Originally I titled the question as "In QNX, what is the difference between _PULSE_CODE_DISCONNECT and _PULSE_CODE_COIDDEATH?". However, I think my question is a little broader than that.
I have implemented an IPC server using the QNX Neutrino OS 6.6.0. Essentially I have a server that is queried for configuration information like settings and stuff. It also accepts changes to settings. It allows for clients to subscribe to it. This means that once subscribed, if a change happens to a setting, the server will notify those other clients.
So far so good. This stuff up to this point makes sense to me. What is not clear to me is the appropriate way to handle a client disconnecting or a process dying.
Right now, I'm receiving a _PULSE_CODE_DISCONNECT on my server. What exactly does that mean? I'm not receiving a _PULSE_CODE_COIDDEATH, which is what I was expecting.
I think in particular I'm a little confused on what a coid vs a scoid is in QNX.
Receiving _PULSE_CODE_COIDDEATH is dependent upon the flags you set when creating the channel. To get that pulse you need to set the channel flag _NTO_CHF_COID_DISCONNECT.
The _PULSE_CODE_DISCONNECT relates to the channel flag _NTO_CHF_DISCONNECT, to receive the pulse when all connections are detached.
See the documentation for the ChannelCreate:
http://www.qnx.com/developers/docs/6.6.0_anm11_wf10/index.html#com.qnx.doc.neutrino.lib_ref/topic/c/channelcreate.html
A coid is a connection id given to you when you connect to a channel via ConnectAttach.
scoid is a server connection id (assigned internally) which you get in the pulse you are talking about. In the message receive and reply context it is for the kernel to route the reply to the client.
Also, my understanding is that if you get the _PULSE_CODE_COIDDEATH you need to cleanup by calling ConnectDetach(scoid) where scoid is from the pulse.
Related
It seems with Django Channels each time anything happens on the websocket there is no persistent state. Even within the same websocket connection, you can not preserve anything between each call to receive() on a class based consumer. If it can't be serialized into the channel_session, it can't be stored.
I assumed that the class based consumer would be persisted for the duration of the web socket connection.
What I'm trying to build is a simple terminal emulator, where a shell session would be created when the websocket connects. Read data would be passed as input to the shell and the shell's output would be passed out the websocket.
I can not find a way to persist anything between calls to receive(). It seems like they took all the bad things about HTTP and brought them over to websockets. With each call to conenct(), recieve(), and disconnect() the whole Consumer class is reinstantiated.
So am I missing something obvious. Can I make another thread and have it read from a Group?
Edit: The answers to this can be found in the comments below. You can hack around it. Channels 3.0 will not instantiate the Consumers on every receive call.
The new version of Channels does not have this limitation. Consumers stay in memory for the duration of the websocket request.
First questions here. I gave searched for this but haven't found any solution which fully answers my problem here. I'm using c++ and need to write a kind of usp chat (server and client) for programs to interact with one another. Well atm it works quite well.
I'm using Googles protobuf as Messages.
I've written it like that:
Server has a list of users curently logged in as well as a list of messages to process and distrubute.
One thread handles all receiving on its socket (I'm using one socket).
If command var in the message is login,
It looks through the list and checks for this combination of port and IP. If not in, the chat creates a new user entry.
If command logout, the server looks for the user in list and deletes it.
If command is message, the server looks if user is logged in and puts it on the message list.
The 2nd thread is for sending.
It waits till there is a message in the list and then cycles through all users to send this messages to their sockets except the sending one.
The server has set options on its socket to receive from any ip.
My question now is: is this the most performat solution?
I've read about select and poll. But it's always about multiple receiving sockets while I have only one.
I know the receiving thread may be idling all the time but in my environment there would be a high frequent message input.
I'm fairly new to socket programming but I think this was the most elegant solution. I was wondering if I could even create another thread which gets a list from receiving thread to process the messages.
Edit: how could I detect time outs?
I mean I could have a variable in the user list which increases or get set to 0. But what if messages won't come frequently. Maybe a server based ping message? Or maybe a flag on the message which get set to acknowledged and gets resend.
On the user side I need to first broadcast to find the server and then set port and up accordingly to the answer. How could I do that?
Because this should run autonomous. Meaning a client should detect dmthe server, login, sends its commands and detect wether it is still online.
On server side I don't know if this is so important. Possibly there might be a memory issue if there are too many things connected and non get logged off. Maybe I set a 1 h timeout to let it detect idle clients.
I have a system where I want to listen to a socket and wait to client connect and then pass the connection to another application that I'll start as soon as the connection is established.
I do not have control on this other application and can only set the port where it will listen, but I want to have one process for each new client.
This is what I'm trying to do:
I've been searching for a solution, but I thing I don't have the right terminology, but I managed to find on Richard Stevens' "Unix Network Programming" something about the AF_ROUTE family of sockets that may be combined with a SOCK_RAW to route a connection to another IP and port. But there's too little documentation about how to use this flag and seems to require superuser privileges (that I want to avoid).
Maybe there's an easier solution but I'm probably using the wrong terms. Is it clear what I want to do?
I don't think you'll be able to just "pass" the socket like you want to, especially if you can't change and recompile "APP". Sockets include various administrative overhead (resource management, etc) that are linked to the process they are owned by. In addition, if you can't recompile APP, there is no way to make it bypass the steps involved with accepting a connection and simple have an already open connected "handed" to it by your router.
However, have you considered simply using router as a pass-through? Basically, have your "Router" process connect via sockets to the each "APP" process it spawns, and simply echo whatever it recieves from the appropriate client to the appropriate APP, and visa versa for APP to client?
This does add overhead, and you will have to manage a small mapping to keep track of which clients go to which apps, but it might work (assuming the APP or client aren't basing any behavior off of the IP address they are connected to, etc). Assuming you can't recompile APP, there might not be too many other options.
The code for this is relatively simple. Your handler for data recieved from APP just looks up the socket for the appropriate app from your mapping, and then does a non blocking send of this data out on it. Likewise the handler for data recieved from client. Depending on how exactly the clients and app behave, you may have to handle a bit of synchronization (if you recieve from both simultaneously).
i am developing client server application in windows using c++ and winsock lib it work fine but if it is on network and once server listening started and if i remove network cable then server doesn't shows any error in any thread so where server socket knows network cable is unplugged.
if any body knows please help me.
While it should be possible to detect that the network cable is unplugged on the host, you will still have the same problem if the network is disrupted somewhere else between your server and the clients.
One common (if not the most common) way to solve this is to have a "keep-alive" message being sent. If no reply to that message is received within some timeout you simply close the connection and release all resources associated with it.
Edit
A "keep-alive" message is like using the "ping" command to see if a remote machine can be reached. It is simply a message that is sent, either by the server or the client (it doesn't matter who initiate it) to see if the other end of the connection is alive and can be reached.
It can be as simple as sending the string "Are you there?" and expecting a reply containing "Yes I am". If you send it once every minute, and don't get a reply withing (for example) one minute, you can consider the connection being dead. The other end, that receives the "Are you there?", knows it will get the message once every minute. If it hasn't arrived for two minutes then the sender is no longer reachable.
If the protocol can't be modified to add such messages, then see if some other message can be used instead.
Also, remember that the best and some cases only way to know if something is wrong with a connection is to attempt to read from the socket.
You can unplug a network and then plug it back in, or your Wi-Fi laptop can lose reception for a second and then pick it back up. It would be frustrating if such resumable cases were treated as an error in all the programs we use.
From this Winsock "newbie" FAQ:
The previous question deals with detecting when a protocol connection is dropped normally, but what if you want to detect other problems, like unplugged network cables or crashed workstations? In these cases, the failure prevents notifying the remote peer that something is wrong. My feeling is that this is usually a feature, because the broken component might get fixed before anyone notices, so why demand that the connection be reestablished?
If you feel you have a "special needs" situation you can be aggressive with timeouts. But I wouldn't do that unless there was a really good reason.
In linux , is it possible to get notification when network connection is down ?
Is the any OS service for which I have to register for such notifications ?
OR is there any DBus Service of it ?
If you're using NetworkManager, it's possible to get status from it (which is, if I remember correctly, done over dbus).
But beware that a lot of Linux machines don't use NetworkManager, so you'll have to handle that. And some machines have more than one network connection, etc.
Further "network connection is down" may not be the most useful thing for you. E.g., it's possible to have a network connection, but the router has lost its Internet connection, so you've only got connectivity to local machines. Or sometimes you'll see partial Internet reachability. Depending on what you need this for, you may need to take other approaches.
Lastly, sometimes network connections die and come back quickly, especially with wireless. These transient changes are probably best ignored (unless the IP address changes).
See this forum thread (linuxquestions.org). Basically you'd need to modify the kernel for pushed notifications. Networkmanager indeed has a DBUS API, but polling periodically is a more general solution.