String compression in EsObject?

[Cusco]

let say I have a chat message like "This is a test from Es Client"
is that EsObject sending between server-client already doing String Compression
like Deflater class in java?

[tcarr]

If the message is sent using a PublicMessageRequest, in the message part of the request and not the EsObject, then it is not compressed. If you configure your ES Admin General Settings to enable compression, EsObjects sent in messages are compressed. There's a trade-off between bandwidth and performance - the compression and decompression take a bit of CPU time, so it's only done for large EsObjects even if you enable compression. For more information see Bandwidth Optimization. (http://www.electrotank.com/docs/es5/manual/bandwidth_optimization.htm)

If you don't want your message to be seen in plaintext by anybody with a packet sniffer on your network, enable encryption (http://www.electrotank.com/docs/es5/manual/enabling_encryption.htm). This takes perhaps 10 seconds for the DH key exchange to set up, then just has a small performance hit that scales with the size of the messages sent after that.

[Cusco]

Thanks~~

about another question
I use the api context.getRemoteAddress().toString();

it got a extra "/" in ipaddress, is it normal?



2011-Aug-13 12:41:43:821 [worker-12 BinaryTCP-0] DEBUG com.electrotank.electroserver5.entities.PeopleImpl - Starting People.login for 229590299992200 / tester
2011-Aug-13 12:41:43:825 [worker-12 BinaryTCP-0] DEBUG com.electrotank.electroserver5.entities.PeopleImpl - User not already logged in, attempting event handlers (if available)
2011-Aug-13 12:41:43:829 [worker-12 BinaryTCP-0] DEBUG Extensions.DatabaseWithJDBC.Plugins.DatabaseActive Record - SELECT SQL_CACHE `id`, `username`, `lastlogin`, `ipaddress` FROM `auth` WHERE `username` = 'tester' AND `password` = '1eeb7f9b69df03ab788f46395a7aecf0547d7fc1' LIMIT 1
2011-Aug-13 12:41:44:208 [worker-12 BinaryTCP-0] DEBUG Extensions.DatabaseWithJDBC.EventHandlers.Database LoginHandler - User 1 : tester logged in ( /54.70.96.136 )
2011-Aug-13 12:41:44:209 [worker-12 BinaryTCP-0] DEBUG Extensions.DatabaseWithJDBC.Plugins.DatabaseActive Record - UPDATE `auth` SET `ipaddress` = '/54.70.96.136'
2011-Aug-13 12:41:44:212 [worker-12 BinaryTCP-0] DEBUG Extensions.DatabaseWithJDBC.EventHandlers.Database LoginHandler - Affected Row: 1
2011-Aug-13 12:41:44:217 [worker-12 BinaryTCP-0] DEBUG com.electrotank.electroserver5.entities.PeopleImpl - User Logged In 229590299992200 / tester
2011-Aug-13 12:41:44:230 [worker-12 BinaryTCP-0] WARN com.electrotank.electroserver5.entities.managers.D efaultExtensionManager - userDidLogin attempt for: DatabaseWithJDBC

[Cusco]

Ref. http://download.oracle.com/javase/6/docs/api/java/net/InetAddress.html#toString()
The string returned is of the form: hostname / literal IP address. If the host name is unresolved, no reverse name service loopup is performed. The hostname part will be represented by an empty string.

is that the api don't escape that / or something?

[tcarr]

I didn't implement that part of the api. If it bothers you, just strip any leading / that you get from that call.

[Cusco]

I have added in common validation class like:


public String removeStroke(String data)
{
Pattern regex = Pattern.compile("[/]+", Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE);
matcher = regex.matcher(data);
data = matcher.replaceAll("");
return data;
}

public boolean matchIP(String data)
{
return data.matches("^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])$");
}

[daperson1]

If you want, I think you can simplify your regex to:


^(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)$

Since "\d" is equivalent to "[0-9]".

[Cusco]

that is a IPv4 address (accurate capture, anchored)
Matches 0.0.0.0 through 255.255.255.255 to match IP numbers with accurracy.
Each of the 4 numbers is stored into a capturing group

if you changed to \d, the regex group will be fail

[daperson1]

Ah. Thanks for that, I'm clearly not as good at regex as I thought I was :P.