B4J Question How to destroy a B4X object?

[LucaMs]

To protect my B4J web socket server, in some cases I want to destroy "web socket handler instances" automatically created when a user connects to my b4j web socket server.

Actually, we (or at least I) do not know how to destroy any object in B4X.
Using VB.Net (or C#) you can use the method Dispose; with B4X?

I have not found documentation in this regard, on site.

 

[Cableguy]

In wich side you want to destroy it?
In client side it will depend of the user platform... in the server side, you need to search for how Java handles the object destruction...
Maybe there's a call to a method you could do with Java object or in line Java ...
In client side, at least in android, you cannot destroy an object yourself... but you could try re-initialing it...

 

[dar2o3]

I looking a little on this subject and I found the following.

http://wiki.eclipse.org/Jetty/Reference/DoSFilter

Not if it is possible to implement with b4j.

 

[LucaMs]

In wich side you want to destroy it?
In client side it will depend of the user platform... in the server side, you need to search for how Java handles the object destruction...
Maybe there's a call to a method you could do with Java object or in line Java ...
In client side, at least in android, you cannot destroy an object yourself... but you could try re-initialing it...

I need it on server side. I don't have references to those objects, they are created in a strange way by Anywhere Software, I think; I don't know if I will be able to find how, but it does not matter. I'm sure that if someone wants to create a web socket server with b4j will have the need to know this (but perhaps few people do).


Thank you, @Cableguy

 

[LucaMs]

I looking a little on this subject and I found the following.

http://wiki.eclipse.org/Jetty/Reference/DoSFilter

Not if it is possible to implement with b4j.

Most likely this is another thing that Anywhere Software should implement.


Thanks, @dar2o3

 

[LucaMs]

To protect my B4J web socket server, in some cases I want to destroy "web socket handler instances" automatically created when a user connects to my b4j web socket server.

Actually, we (or at least I) do not know how to destroy any object in B4X.
Using VB.Net (or C#) you can use the method Dispose; with B4X?

I have not found documentation in this regard, on site.

My question was not well specified.

It is not for security reasons, not exactly; I can close the websocket object when I want/need, but this object is inside a "web socket handler instance" and this one will remain in memory, of course, and we need to "remove" (release, dispose) it.

As any other B4X object, we don't know how to destroy them to free memory.

 

[LucaMs]

Right now I'm reading the server side source code of "Custom WebSocket Based Push Framework" (here the source code).

The project uses a map to stores all "connections" (note that it does not stores websocket objects but websocket handler objects).

When a "websocket handler instance"'s websocket disconnects (WebSocket_Disconnected) a public routine of a code module will be called:

Private Sub WebSocket_Disconnected
    If id <> "" Then CallSubDelayed3(PushShared, "RemoveConnection", id, Me)
End Sub

id is an identifier ("property") of the websocket handler instance; so, to "RemoveConnection", the instance and the "instance id" will be passed.

Here the (at least) strange code of "RemoveConnection":

Public Sub RemoveConnection(Id As String, pb As PushB4A)
    If pb <> ActiveConnections.Get(Id) Then Return 'this can happen if there was a "phantom" connection

ActiveConnections.Get(Id) should return the PushB4A object stored (PushB4A is an instance of the websocket handler class) but...
'this can happen if there was a "phantom" connection

It's not so clear, for me, but I fear it is related rightly to my question: where websocket handler instances are stored and how to destroy them.
Note that RemoveConnection only removes the websocket handler instance (PushB4A object) from a map, which does not contain the object but a reference to it.

Well, if a hacker will try to access your B4J websocket server thousands or millions of times in a short time, your server will create thousands or millions of objects on your server.

For this reason, probably, because you can not destroy websocket handler objects, this happened:
The online example is currently disabled due to spam
(you can read the above phrase at the top of the tutorial)

You could check the user's IP address and if it is repeated too many times in a short time, you... should destroy the PushB4A objects, not just close the websocket connection.




P.S. that "id" should be the user device id; probably for this reason there can be a "phantom" connection.

 

[OliverA]

Well, if a hacker will try to access your B4J websocket server thousands or millions of times in a short time, your server will create thousands or millions of objects on your server, this is sure.
VERY NICE

Maybe this should be handled below the application stack. When I had an ssh server available via my public interface, ssh had no protection for "flooding". Instead I used iptables to ward off such attacks - see point#17 at http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html . More useful tools are mentioned in point #16 of the same link.

 

[LucaMs]

Maybe this should be handled below the application stack. When I had an ssh server available via my public interface, ssh had no protection for "flooding". Instead I used iptables to ward off such attacks - see point#17 at http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html . More useful tools are mentioned in point #16 of the same link.

I think not only to "flooding".

Even if you do not receive attacks by hackers, if your server remains continuously active (months, years), it will store (in memory) all websocket handler objects created from its start and they can be millions or even billions.

Do you agree?

 

[OliverA]

I think not only to "flooding".

Even if you do not receive attacks by hackers, if your server remains continuously active (months, years), it will store (in memory) all websocket handler objects created from its start and they can be millions or even billions.

Do you agree?

1) Depends how these objects are affected by garbage collection.

2) I don't know of too many servers that don't get restarted now and then.

 

[LucaMs]

1) Depends how these objects are affected by garbage collection.

You should be able, at least, to set them to Null (although I do not think this would be enough) but you don't have access to those objects, you have no control on them.

 

[OliverA]

You should be able, at least, to set them to Null (although I do not think this would be enough) but you don't have access to those objects, you have no control on them.

If there is no reference to them, then the Java vm should act accordingly and remove them via garbage collection.

 

[LucaMs]

If there is no reference to them, then the Java vm should act accordingly and remove them via garbage collection.

There is always a reference to that kind of object (after a client connection) but it is not created by your b4j code.

 

[Erel]

If there is no reference to them, then the Java vm should act accordingly and remove them via garbage collection.

That's correct. And it is also the case with server handlers. Once the WebSocket has disconnected then it will be released (assuming that you are not holding a reference yourself).

The online example is currently disabled due to spam

You are keep saying this however it has nothing to do with memory handling. It was an open example and someone (1) has started sending spam through it.

B4J servers can run for months or years without a restart, unless you are doing something wrong in the application level.

 

[LucaMs]

Once the WebSocket has disconnected then it will be released (assuming that you are not holding a reference yourself).

This is the info I needed.

Thank you.

 

[LucaMs]

Once the WebSocket has disconnected then it will be released

So, in this case:

It was an open example and someone (1) has started sending spam through it.

if you have an "IP black list" you could close the websocket if [...] and then the GC will destroy the websocket handler object (sooner or later).

(I know the hacker can change his IP or he can...)

 

[OliverA]

if you have an "IP black list" you could close the websocket if [...] and then the GC will destroy the websocket handler object (sooner or later).

Once on an "IP black list", you should not even let them open a websocket to begin with. No websocket, no object to worry about having to be cleaned up.

 

[LucaMs]

Once on an "IP black list", you should not even let them open a websocket to begin with. No websocket, no object to worry about having to be cleaned up.

But you can (only, I think) get the client IP from a connected websocket (ws.UpgradeRequest.RemoteAddress)

 

[OliverA]

But you can (only, I think) get the client IP from a connected websocket (ws.UpgradeRequest.RemoteAddress)

Disclaimer: I've not done any jServer programming and everything here comes from gleaning some source files and the community site.

You can also get the client IP from the ServletRequest object. You can use AddFilter to set up a filter for your site

srvr.AddFilter("/*", "FilterAllTheBadStuff", False)

and then filter out all the junk you want before a websocket is established. Of course now you have ServletRequest objects that need to be handled by the GC. In a sense we are only throwing about a hypothetical question as to the effectiveness of jServer when it comes to cleaning up dead objects. Technically one should probably set up a test case and bombard the server and see how it reacts. It may be that the filter is enough. If not, external solutions may need to be recruited (the IP address could be passed to them and then they take care of blocking anything before it gets to the jServer). Above all, this may actually be just a small tiny portion of what can affect the jServer, with the application itself probably being the biggest culprit (mentioned by Erel in a previous post).

 

[dar2o3]

Do not worry, jetty is more than proven and sure makes cleaning work memory famously, on the other hand, ISPs normally have DDoS protection entree many others, I have a server websockets in a Pi 2 funcinando raspberry without stop for more than 6 months without any problem memory for use AddHandler login page and once logged in and use AddWebSocket where I need.
I'm creating a tool for testing server websockets and 300 open connections websockets memory consumption in the raspberry is quite low.