Hello, could you please tell me how I can close (disconnect) a clients' socket in a SFS Java extension within a handleInternalEvent() method, in case user fails against auth procedure?
If I just call return from this method, the socket is closed only after MaxSocketIdleTime seconds defined in config.xml, whis is not desirable behaviour for me.
If auth procedure fails for a user, I have to send some error message to the socket and then close the socket immediately, but if I call channel.socket().close(), or just channel.close() right after sending an error message, the message will not be send, cause close() does not wait for processing message query I guess.
So, what's the best way to send a message and close a client's socket?
Thanks!
closing client's socket
Re: closing client's socket
Hi,
a good way to do this would be to receive the error message on the client side and disconnect from there.
This way you can make sure that the message was received.
If you disconnect immediately after the error message, from server side, the user may not receive it.
cheers
a good way to do this would be to receive the error message on the client side and disconnect from there.
This way you can make sure that the message was received.
If you disconnect immediately after the error message, from server side, the user may not receive it.
cheers
Re: closing client's socket
Of cause you are right, but only in case if we can absolutely trust the client.
If not (as in my case) I have to deal with fully sockets management on a server side to avoid ddos o something insecure and unwanted behaviour from the clients.
If not (as in my case) I have to deal with fully sockets management on a server side to avoid ddos o something insecure and unwanted behaviour from the clients.
Re: closing client's socket
I see.
From server side you can call the close() method directly on the socket channel passed in the login event.
cheers
From server side you can call the close() method directly on the socket channel passed in the login event.
cheers
Re: closing client's socket
But it doesn't allow to send a message before closing the socket.
Re: closing client's socket
Well, not in one call, of course.
You can send the message and delay the socket shut down by a while, e.g. a couple of seconds, thus ensuring that the message has made it to the other side.
To delay the operation you can use a ScheduledExecutor from the standard JDK API.
http://docs.oracle.com/javase/7/docs/ap ... rvice.html
hope it helps
You can send the message and delay the socket shut down by a while, e.g. a couple of seconds, thus ensuring that the message has made it to the other side.
To delay the operation you can use a ScheduledExecutor from the standard JDK API.
http://docs.oracle.com/javase/7/docs/ap ... rvice.html
hope it helps
Re: closing client's socket
Thanks. but it's not a robust, simple and reliable solution. How long I must wait? How can I compute the minimum an maximum time to wait, where is the guarantee that all messages will be send anyway? Sorry for my punctuality...
I can just call return from the handleInternalEvent() and let the MaxSocketIdleTime setting do it's job. SFS will disconnect and close a socket and all queried messages will be send through the socket. The main disadvantage of it is will be resources leakage in case of ddos attack.
I thought that it's possible to do it without a delay but I guess no...
Thanks again for your help.
I can just call return from the handleInternalEvent() and let the MaxSocketIdleTime setting do it's job. SFS will disconnect and close a socket and all queried messages will be send through the socket. The main disadvantage of it is will be resources leakage in case of ddos attack.
I thought that it's possible to do it without a delay but I guess no...
Thanks again for your help.
Re: closing client's socket
Mhollow wrote:Thanks. but it's not a robust, simple and reliable solution. How long I must wait? How can I compute the minimum an maximum time to wait, where is the guarantee that all messages will be send anyway? Sorry for my punctuality...
I would confidently say that the vast majority of cases are covered with a 1-2 second delay before disconnection.
This might not cover corner cases of very congested networks, but I can't see how a client network can be congested if it's just started with a connection. I think one could choose a compromise where 1 in 1000 cases will not see the error message.
If you want to be overscrupulous this idea should be tested for all TCP implementations (browsers, mobile devices etc...) in a variety of network conditions, since they may all behave slightly differently.
I can just call return from the handleInternalEvent() and let the MaxSocketIdleTime setting do it's job. SFS will disconnect and close a socket and all queried messages will be send through the socket. The main disadvantage of it is will be resources leakage in case of ddos attack.
DDos attacks are rarely defeated with socket timeouts anyways. Maybe for small attemtps, but massive ones require well configured firewalls at least.
For more on this see here:
https://devcentral.f5.com/articles/laye ... dos-attack
cheers
Return to “Server Side Extension Development”
Who is online
Users browsing this forum: No registered users and 51 guests