I use PJNATH to connect with webrtc datachannele. It can send and receive data now. But i don't known when the other peer disconnect. Although I can check connecton disconnect by heartbeat in application layer,but i think it not the best choice. Is anyone who familiar with PJNATH can give me some suggest?
thanks~
Related
is it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
Furthermore to be notified when a keepalive is sent?
Without resorting to packet-level filtering in a kernel driver?
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server. At the moment our best option I think is just to allow setting keepalives on the server-side connection, but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Thanks.
it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
No. TCP keepalive doesn't use a protocol extension. It just uses the existing protocol in a specific way so as to provoke a response.
Furthermore to be notified when a keepalive is sent?
No. A TCP keepalive segment cannot be identified as such.
Without resorting to packet-level filtering in a kernel driver?
Not even if you do.
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server.
Your customer is misinformed.
At the moment our best option I think is just to allow setting keepalives on the server-side connection
Correct.
but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Not possible.
I m trying to make the com.sun.net.httpserver work with WebSocket.
I was able to do the handshake and the browser gets connected then directly disconnect.
is there anyway to make the websocket work with com.sun.net.httpserver ?
Can anyone help me with this issue.
Thank you
Provided that you somehow successfully established an authenticated secure websocket connection, would that connection be considered safe from then on? Meaning, do you have to send authentication data with each message so that if an attacker somehow connects to the already established websocket, they can't send anything meaningful? I assume for wss connections such a condition can't occur, but what about a regular ws connection?
A WebSocket is a point-to-point connection, so nobody else can connect to that particular socket. If you're using current cyphers for the TLS, then this should be secure (there are cyphers out there which are being deprecated at the moment since they are/may be broken).
For a non-TLS WebSocket connection the same goes as for anything done over regular HTTP (or any other unencrypted protocol): any intermediary can alter the data, so this cannot be considered secure.
Here is a good 2 part blog post on WebSocket security that should help you:
http://blog.kaazing.com/2012/02/28/html5-websocket-security-is-strong/
Case:
A WebSocket connection have been established between the client and server endpoint.
Now I have the network connection go down (for example the ADSL dies), after 10 min I recover the network, I find that the client and server are still able to communicate with each
other. Why?
Note:
The client was developed with Java-WebSocket framework, and the client did with ws4py.
1 - If they did not try to exchange any data and only the connection (not the endpoints) between them is down, this is normal behaviour.
2 - If the websocket connection ended, Browser may have re-established it without you knowing about it. I just checked that this is not normal behaviour. But maybe there is some parameter somewhere :-)
Imagine you have a server which can handle only one client at a time. The server uses WSAAsyncSelect to be notified of new connections. In this case, what is the best way of handling FD_ACCEPT messages:
A > Accept the connection attempt right away but queue the client until its turn?
B > Do not accept the next connection attempt until we are done serving the currently connected client?
What do you guys think is the most efficient?
Here I describe the cons that I'm aware for both options. Hopefully this might help you decide.
A)
Upon a new client connection, it could send tons of data making your receive buffer become full, which causes unnecessary packets to be transmitted (see this). If you don't plan to receive any data from the client, shutdown receiving on that socket, thus if the client sends any data after that, the connection is reset. Moreover, if your protocol has strict rules, disconnect the client.
If the connection stays idle for too long, the system might disconnect it. To solve this, use setsockopt to set SO_KEEPALIVE on each client socket.
B)
If you don't accept the connection after a certain period (I guess the default is 60 seconds), it will timeout. In a normal (or most common) situation this indicates the server is overloaded, thus unable to answer in time. However, if the client is also designed by you, make the socket non-blocking, try to connect, then manage the timeout as you wish.
Ask yourself: what do you want the user experience to be at the other end? Do you want them to be stuck? Do you want them to time out? Do you want them to get a polite message?