closing client's socket

Post here your questions about Actionscript and Java server side extensions development.

Moderators: Lapo, Bax

Mhollow
Posts: 24
Joined: 22 Feb 2012, 06:29
Location: Russia

closing client's socket

Postby Mhollow » 30 Jun 2015, 06:47

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!
User avatar
Lapo
Site Admin
Posts: 19941
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: closing client's socket

Postby Lapo » 30 Jun 2015, 08:59

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
Lapo
--
gotoAndPlay()
...addicted to flash games
Mhollow
Posts: 24
Joined: 22 Feb 2012, 06:29
Location: Russia

Re: closing client's socket

Postby Mhollow » 30 Jun 2015, 09:13

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.
User avatar
Lapo
Site Admin
Posts: 19941
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: closing client's socket

Postby Lapo » 30 Jun 2015, 09:36

I see.
From server side you can call the close() method directly on the socket channel passed in the login event.

cheers
Lapo

--

gotoAndPlay()

...addicted to flash games
Mhollow
Posts: 24
Joined: 22 Feb 2012, 06:29
Location: Russia

Re: closing client's socket

Postby Mhollow » 30 Jun 2015, 10:19

But it doesn't allow to send a message before closing the socket.
User avatar
Lapo
Site Admin
Posts: 19941
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: closing client's socket

Postby Lapo » 30 Jun 2015, 11:08

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
Lapo

--

gotoAndPlay()

...addicted to flash games
Mhollow
Posts: 24
Joined: 22 Feb 2012, 06:29
Location: Russia

Re: closing client's socket

Postby Mhollow » 30 Jun 2015, 12:02

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.
User avatar
Lapo
Site Admin
Posts: 19941
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: closing client's socket

Postby Lapo » 30 Jun 2015, 14:40

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
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “Server Side Extension Development”

Who is online

Users browsing this forum: Google [Bot] and 10 guests