[vysper][pubsub] GSoC final weeks
Hi Michael, As the GSoC'09 is nearing 'pencils down' state, I'm thinking about how to showcase PubSub in an easy way. New features are not critical, AFAIAC. My proposal is to implement a simple Swing application, featuring: + a simple UI, with the following forms: a. JID edit field (EF), hostname EF, password EF, login button b. Node name EF, subscribe button, unsubscribe button c. Text area, publish-to-node button d. Text area for displaying messages + Use case: Login User specifies JID + password, when hitting login, the user get's logged into the server given by hostname + Use case: Subscribe to a node User enters node name and hits subscribe. Client creates the node, if not already existing. Client sends subscription request. Server subscribes JID to the node + Use case: Unsubscribe from node ... canonical ... + Use case: Publish User enters a message (not whole stanza) into the text area, hits publish... Client publishes the message to the node on the server + Use case: Receive pubsub messages Client displays messages coming from the server in the display area WDYT? Bernd
Re: [vysper][pubsub] GSoC final weeks
Hi! On Wed, Aug 5, 2009 at 11:35, Bernd Fondermannbf_...@brainlounge.de wrote: As the GSoC'09 is nearing 'pencils down' state, I'm thinking about how to showcase PubSub in an easy way. New features are not critical, AFAIAC. Thanks! I was just plotting how to integrate the various access-models which seems more tricky than I thought. Maybe we'll need to discuss them at a given time. My proposal is to implement a simple Swing application, featuring: + a simple UI, with the following forms: a. JID edit field (EF), hostname EF, password EF, login button b. Node name EF, subscribe button, unsubscribe button c. Text area, publish-to-node button d. Text area for displaying messages + Use case: Login User specifies JID + password, when hitting login, the user get's logged into the server given by hostname + Use case: Subscribe to a node User enters node name and hits subscribe. Client creates the node, if not already existing. Client sends subscription request. Server subscribes JID to the node + Use case: Unsubscribe from node ... canonical ... + Use case: Publish User enters a message (not whole stanza) into the text area, hits publish... Client publishes the message to the node on the server + Use case: Receive pubsub messages Client displays messages coming from the server in the display area WDYT? Showing a real world example would do more good (and is in line with our GSoC proposal) than implementing more features of the spec. Even though I've got more experience with webapps than any other UI technology, they would not be able to show the advantages of the pubsub approach. I'll start right now, building on top of my previous example. Where should I put the code? Michael
Re: [vysper][pubsub] GSoC final weeks
On Wed, Aug 5, 2009 at 13:36, Michael Jakljakl.mich...@gmail.com wrote: Hi! On Wed, Aug 5, 2009 at 11:35, Bernd Fondermannbf_...@brainlounge.de wrote: As the GSoC'09 is nearing 'pencils down' state, I'm thinking about how to showcase PubSub in an easy way. New features are not critical, AFAIAC. Thanks! I was just plotting how to integrate the various access-models which seems more tricky than I thought. Maybe we'll need to discuss them at a given time. My proposal is to implement a simple Swing application, featuring: + a simple UI, with the following forms: a. JID edit field (EF), hostname EF, password EF, login button b. Node name EF, subscribe button, unsubscribe button c. Text area, publish-to-node button d. Text area for displaying messages + Use case: Login User specifies JID + password, when hitting login, the user get's logged into the server given by hostname + Use case: Subscribe to a node User enters node name and hits subscribe. Client creates the node, if not already existing. Client sends subscription request. Server subscribes JID to the node + Use case: Unsubscribe from node ... canonical ... + Use case: Publish User enters a message (not whole stanza) into the text area, hits publish... Client publishes the message to the node on the server + Use case: Receive pubsub messages Client displays messages coming from the server in the display area WDYT? Showing a real world example would do more good (and is in line with our GSoC proposal) than implementing more features of the spec. Even though I've got more experience with webapps than any other UI technology, they would not be able to show the advantages of the pubsub approach. wouldn't they? you would only need to need to get JabberHTTPBind [1] and jwchat [2] running within a webcontainer and connect it to Vysper. But be careful! You can loose a lot of time doing that! [1] http://blog.jwchat.org/jhb/ [2] http://blog.jwchat.org/jwchat/ I'll start right now, building on top of my previous example. +1 Where should I put the code? Anyone objecting to mina/sandbox/vysper/trunk/demo/pubsub/client ? Bernd
[jira] Created: (FTPSERVER-321) Typo in the log message
Typo in the log message --- Key: FTPSERVER-321 URL: https://issues.apache.org/jira/browse/FTPSERVER-321 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Priority: Trivial Fix For: 1.0.3 Fix the typo in DataConnectionConfig class on the following log message: log.info(We're waiting for a passive part, might be stuck); passive part should have been passive port. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vysper][pubsub] GSoC final weeks
Hi! On Wed, Aug 5, 2009 at 14:04, Bernd Fondermannbernd.fonderm...@googlemail.com wrote: On Wed, Aug 5, 2009 at 13:36, Michael Jakljakl.mich...@gmail.com wrote: Even though I've got more experience with webapps than any other UI technology, they would not be able to show the advantages of the pubsub approach. wouldn't they? you would only need to need to get JabberHTTPBind [1] and jwchat [2] running within a webcontainer and connect it to Vysper. But be careful! You can loose a lot of time doing that! [1] http://blog.jwchat.org/jhb/ [2] http://blog.jwchat.org/jwchat/ Thanks for the hint, it looks nice, but I'll stay away from more experiments right now :) Michael
Re: FTPS with passive mode is slow
Okay, done! I also have another question around the same code...Should we be checking the remote address and make sure it matches with the IP address of the remote host on the control connection. If we do not do this check, it is possible for a hacker to connect to this port before the original client and may gain access to the data? I know it is not very easy to do this, but just in case. What do you think? Sai Pullabhotla www.jMethods.com On Tue, Aug 4, 2009 at 3:48 PM, Niklas Gustavssonnik...@protocol7.com wrote: I believe this problem has been reported multiple times. Please open a JIRA and apply the patch, it makes perfect sense. /niklas On Tue, Aug 4, 2009 at 10:02 PM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: I've been noticing that the passive data connections are taking quite some time when using SSL. I finally got some time to look into this and noticed the following while debugging through the code. This issue might have been introduced with the fix we put in for FTPSERVER-241. The code that wraps the plain socket into an SSL socket uses the following line: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket.getInetAddress().getHostName(), serverSocket.getPort(), true); Based on the JavaDocs, the InetAddress.getHostName() performs a reverse name look up, which was taking about 1.5 seconds on every system on our network. I'm not sure if this is an issue with the way our network is setup. Some one please let me know if this in fact an issue with our network. We are not seeing this lag when client and server are running on the same system. Things work too fast in this case, probably because the system knows very well about itself. Just to try it out, I changed the code to simply use the IP address rather than the host name, and I was able to get rid of the lag and things seem to be working much faster. Below is the change to the above line: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket.getInetAddress().getHostAddress(), serverSocket.getPort(), true); Could some one test the current code base with client and server running on different systems and tell me if they notice the lag when creating the passive data connection. If this can be reproduced on one of your environments, we should probably put the above fix. I don't think this suggested fix should cause any other issues, do you? Regards, Sai Pullabhotla www.jMethods.com
[jira] Commented: (DIRMINA-734) Regression with flushing in MINA 2.0.0-M7 trunk
[ https://issues.apache.org/jira/browse/DIRMINA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739506#action_12739506 ] Emmanuel Lecharny commented on DIRMINA-734: --- Assuming your system works like that : Client === Proxy === Application do you close the session when the Application has sent its last message, or are you expecting some more message to be received ? In other words, do you close here : Client --- proxy --- Application --+ Client --- proxy -*- Application--+ (when the message is received from the application, '*' being the message) or here : Client --- proxy -*- Application --+ Client --- proxy --- Application--+ (just after having transmitted the message to the application) Otherwise, the session code hasn't been changed in this area since last release. Regression with flushing in MINA 2.0.0-M7 trunk --- Key: DIRMINA-734 URL: https://issues.apache.org/jira/browse/DIRMINA-734 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M7 Reporter: Serge Baranov It looks like the present trunk of MINA in the repository has a bug. Updating from M7 built on 06.06.2009 to the current trunk broke some of our tests. I've tried to build it today and ran our application tests, some of them failed. Reverting back to 06.06.2009 build has fixed the problem. At the first look it appears that session.close(false) behaves like session.close(true), as a result some messages are truncated (not being flushed on session.close(false)). If I comment out a call to session.close(false) (i.e. not closing the session at all when needed), the problem goes away. This behavior is inconsistent, test fails/succeeds randomly. On the first run it may pass, on the second run it may fail. Test fails about 10% of runs. The part which is not flushed is also random. Could be a race condition somewhere in MINA introduced in the last 2 months. I can't provide a test case yet, but our application is a kind of proxy, so it behaves like this: 1. client connects to the app and send a request 2. app connects to another server and sends a request 3. app gets a reply from the server and sends it back to the client 4. when another server closes the connection, app is closing the connection with the client using session.close(false) The app may be still flushing data to client when closing the connection. As I said it worked fine with previous MINA versions, but has broken only recently. We are using OrderedThreadPoolExecutor and CumulativeProtocolDecoder if that matters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VYSPER-158) Introduce the various affiliations a user can have
[ https://issues.apache.org/jira/browse/VYSPER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jakl resolved VYSPER-158. - Resolution: Fixed Fixed in rev801238 Introduced the concept of affiliation and privilege into the pubsub module. Currently the creator of a node is the owner, and hence is allowed to publish, delete etc. Everyone else is only a member (open-access model) and is allowed to subscribe. Introduce the various affiliations a user can have -- Key: VYSPER-158 URL: https://issues.apache.org/jira/browse/VYSPER-158 Project: VYSPER Issue Type: Sub-task Components: XEP0060 PubSub Reporter: Michael Jakl Assignee: Michael Jakl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-734) Regression with flushing in MINA 2.0.0-M7 trunk
[
https://issues.apache.org/jira/browse/DIRMINA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739518#action_12739518
]
Serge Baranov commented on DIRMINA-734:
---
The application based on MINA it a proxy by itself, so it would be:
client our application based on mina some server
When the server closes connection, application closes connection with the
client using session.close(false), same as in the example provided with MINA:
mina\example\src\main\java\org\apache\mina\example\proxy\AbstractProxyIoHandler.java:
public void sessionClosed(IoSession session) throws Exception {
if (session.getAttribute( OTHER_IO_SESSION ) != null) {
IoSession sess = (IoSession) session.getAttribute(OTHER_IO_SESSION);
sess.setAttribute(OTHER_IO_SESSION, null);
sess.close(false);
session.setAttribute(OTHER_IO_SESSION, null);
}
}
Regression with flushing in MINA 2.0.0-M7 trunk
---
Key: DIRMINA-734
URL: https://issues.apache.org/jira/browse/DIRMINA-734
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-M7
Reporter: Serge Baranov
It looks like the present trunk of MINA in the repository
has a bug. Updating from M7 built on 06.06.2009 to the current trunk
broke some of our tests.
I've tried to build it today and ran our application tests, some of
them failed.
Reverting back to 06.06.2009 build has fixed the problem.
At the first look it appears that session.close(false) behaves like
session.close(true), as a result some messages are truncated (not
being flushed on session.close(false)).
If I comment out a call to session.close(false) (i.e. not closing the
session at all when needed), the problem goes away.
This behavior is inconsistent, test fails/succeeds randomly. On the
first run it may pass, on the second run it may fail. Test fails about
10% of runs. The part which is not flushed is also random. Could be a
race condition somewhere in MINA introduced in the last 2 months.
I can't provide a test case yet, but our application is a kind of
proxy, so it behaves like this:
1. client connects to the app and send a request
2. app connects to another server and sends a request
3. app gets a reply from the server and sends it back to the client
4. when another server closes the connection, app is closing the
connection with the client using session.close(false)
The app may be still flushing data to client when closing the
connection. As I said it worked fine with previous MINA versions, but
has broken only recently.
We are using OrderedThreadPoolExecutor and CumulativeProtocolDecoder
if that matters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-734) Regression with flushing in MINA 2.0.0-M7 trunk
[
https://issues.apache.org/jira/browse/DIRMINA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739518#action_12739518
]
Serge Baranov edited comment on DIRMINA-734 at 8/5/09 7:15 AM:
---
The application based on MINA is a proxy by itself, so it would be:
client our application based on mina some server
When the server closes connection, application closes connection with the
client using session.close(false), same as in the example provided with MINA:
mina\example\src\main\java\org\apache\mina\example\proxy\AbstractProxyIoHandler.java:
public void sessionClosed(IoSession session) throws Exception {
if (session.getAttribute( OTHER_IO_SESSION ) != null) {
IoSession sess = (IoSession) session.getAttribute(OTHER_IO_SESSION);
sess.setAttribute(OTHER_IO_SESSION, null);
sess.close(false);
session.setAttribute(OTHER_IO_SESSION, null);
}
}
was (Author: crazycoder):
The application based on MINA it a proxy by itself, so it would be:
client our application based on mina some server
When the server closes connection, application closes connection with the
client using session.close(false), same as in the example provided with MINA:
mina\example\src\main\java\org\apache\mina\example\proxy\AbstractProxyIoHandler.java:
public void sessionClosed(IoSession session) throws Exception {
if (session.getAttribute( OTHER_IO_SESSION ) != null) {
IoSession sess = (IoSession) session.getAttribute(OTHER_IO_SESSION);
sess.setAttribute(OTHER_IO_SESSION, null);
sess.close(false);
session.setAttribute(OTHER_IO_SESSION, null);
}
}
Regression with flushing in MINA 2.0.0-M7 trunk
---
Key: DIRMINA-734
URL: https://issues.apache.org/jira/browse/DIRMINA-734
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-M7
Reporter: Serge Baranov
It looks like the present trunk of MINA in the repository
has a bug. Updating from M7 built on 06.06.2009 to the current trunk
broke some of our tests.
I've tried to build it today and ran our application tests, some of
them failed.
Reverting back to 06.06.2009 build has fixed the problem.
At the first look it appears that session.close(false) behaves like
session.close(true), as a result some messages are truncated (not
being flushed on session.close(false)).
If I comment out a call to session.close(false) (i.e. not closing the
session at all when needed), the problem goes away.
This behavior is inconsistent, test fails/succeeds randomly. On the
first run it may pass, on the second run it may fail. Test fails about
10% of runs. The part which is not flushed is also random. Could be a
race condition somewhere in MINA introduced in the last 2 months.
I can't provide a test case yet, but our application is a kind of
proxy, so it behaves like this:
1. client connects to the app and send a request
2. app connects to another server and sends a request
3. app gets a reply from the server and sends it back to the client
4. when another server closes the connection, app is closing the
connection with the client using session.close(false)
The app may be still flushing data to client when closing the
connection. As I said it worked fine with previous MINA versions, but
has broken only recently.
We are using OrderedThreadPoolExecutor and CumulativeProtocolDecoder
if that matters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [vysper][pubsub] GSoC final weeks
On Wed, Aug 5, 2009 at 2:04 PM, Bernd Fondermannbernd.fonderm...@googlemail.com wrote: Where should I put the code? Anyone objecting to mina/sandbox/vysper/trunk/demo/pubsub/client ? Looks good to me. Will be interesting to have a go playing with the pubsub support :-) /niklas
Re: FTPS with passive mode is slow
On Wed, Aug 5, 2009 at 2:41 PM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: I also have another question around the same code...Should we be checking the remote address and make sure it matches with the IP address of the remote host on the control connection. If we do not do this check, it is possible for a hacker to connect to this port before the original client and may gain access to the data? I know it is not very easy to do this, but just in case. What do you think? I think this makes sense. We already do the logically same for active connections. Probably only should apply this to the 1.1.X (trunk) code, right? /niklas
[jira] Commented: (DIRMINA-734) Regression with flushing in MINA 2.0.0-M7 trunk
[ https://issues.apache.org/jira/browse/DIRMINA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739540#action_12739540 ] Emmanuel Lecharny commented on DIRMINA-734: --- It's difficult to know what is happening here, without a sample demonstrating the problem. There have been some fixes in the ExecutorFilter since last release, but they were quite necessary. I'm trying to list all the important changes since M6. Regression with flushing in MINA 2.0.0-M7 trunk --- Key: DIRMINA-734 URL: https://issues.apache.org/jira/browse/DIRMINA-734 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M7 Reporter: Serge Baranov It looks like the present trunk of MINA in the repository has a bug. Updating from M7 built on 06.06.2009 to the current trunk broke some of our tests. I've tried to build it today and ran our application tests, some of them failed. Reverting back to 06.06.2009 build has fixed the problem. At the first look it appears that session.close(false) behaves like session.close(true), as a result some messages are truncated (not being flushed on session.close(false)). If I comment out a call to session.close(false) (i.e. not closing the session at all when needed), the problem goes away. This behavior is inconsistent, test fails/succeeds randomly. On the first run it may pass, on the second run it may fail. Test fails about 10% of runs. The part which is not flushed is also random. Could be a race condition somewhere in MINA introduced in the last 2 months. I can't provide a test case yet, but our application is a kind of proxy, so it behaves like this: 1. client connects to the app and send a request 2. app connects to another server and sends a request 3. app gets a reply from the server and sends it back to the client 4. when another server closes the connection, app is closing the connection with the client using session.close(false) The app may be still flushing data to client when closing the connection. As I said it worked fine with previous MINA versions, but has broken only recently. We are using OrderedThreadPoolExecutor and CumulativeProtocolDecoder if that matters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FTPS with passive mode is slow
I'm not sure, I think it should go to the main trunk as well. Sai Pullabhotla www.jMethods.com On Wed, Aug 5, 2009 at 9:31 AM, Niklas Gustavssonnik...@protocol7.com wrote: On Wed, Aug 5, 2009 at 2:41 PM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: I also have another question around the same code...Should we be checking the remote address and make sure it matches with the IP address of the remote host on the control connection. If we do not do this check, it is possible for a hacker to connect to this port before the original client and may gain access to the data? I know it is not very easy to do this, but just in case. What do you think? I think this makes sense. We already do the logically same for active connections. Probably only should apply this to the 1.1.X (trunk) code, right? /niklas
[jira] Updated: (DIRMINA-734) Regression with flushing in MINA 2.0.0-M7 trunk
[ https://issues.apache.org/jira/browse/DIRMINA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Serge Baranov updated DIRMINA-734: -- Attachment: mina-flush-regression.zip I've prepared and attached a test for this issue. It's based on the MINA proxy example. Please see the instructions inside README.txt. This scenario requires an Apache server to reproduce, however you can use some large html page instead hosted on any public server, just change the options used for running the proxy and the client. Regression with flushing in MINA 2.0.0-M7 trunk --- Key: DIRMINA-734 URL: https://issues.apache.org/jira/browse/DIRMINA-734 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M7 Reporter: Serge Baranov Attachments: mina-flush-regression.zip It looks like the present trunk of MINA in the repository has a bug. Updating from M7 built on 06.06.2009 to the current trunk broke some of our tests. I've tried to build it today and ran our application tests, some of them failed. Reverting back to 06.06.2009 build has fixed the problem. At the first look it appears that session.close(false) behaves like session.close(true), as a result some messages are truncated (not being flushed on session.close(false)). If I comment out a call to session.close(false) (i.e. not closing the session at all when needed), the problem goes away. This behavior is inconsistent, test fails/succeeds randomly. On the first run it may pass, on the second run it may fail. Test fails about 10% of runs. The part which is not flushed is also random. Could be a race condition somewhere in MINA introduced in the last 2 months. I can't provide a test case yet, but our application is a kind of proxy, so it behaves like this: 1. client connects to the app and send a request 2. app connects to another server and sends a request 3. app gets a reply from the server and sends it back to the client 4. when another server closes the connection, app is closing the connection with the client using session.close(false) The app may be still flushing data to client when closing the connection. As I said it worked fine with previous MINA versions, but has broken only recently. We are using OrderedThreadPoolExecutor and CumulativeProtocolDecoder if that matters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VYSPER-171) Retrieve Affiliations (XEP-0060 5.7)
Retrieve Affiliations (XEP-0060 5.7) Key: VYSPER-171 URL: https://issues.apache.org/jira/browse/VYSPER-171 Project: VYSPER Issue Type: New Feature Components: XEP0060 PubSub Reporter: Michael Jakl http://xmpp.org/extensions/tmp/xep-0060-1.13.html#entity-affiliations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vysper][pubsub] GSoC final weeks
On Wed, Aug 5, 2009 at 16:25, Niklas Gustavssonnik...@protocol7.com wrote: On Wed, Aug 5, 2009 at 2:04 PM, Bernd Fondermannbernd.fonderm...@googlemail.com wrote: Where should I put the code? Anyone objecting to mina/sandbox/vysper/trunk/demo/pubsub/client ? Looks good to me. Will be interesting to have a go playing with the pubsub support :-) How shall we cope with the special smack libs? It seems that the required smack lib is from the development branch. For reference the URL again: http://github.com/squaremo/smackx-pubsub/tree/master Michael
Dong Qun Li is out of the office.
I will be out of the office starting 2009-08-06 and will not return until 2009-08-20. Please kindly contact Yan Yan BJ Su/China/Contr/IBM for build/IT issues, any emergency , pls call my cellphone: 13391982731
Re: FTPS with passive mode is slow
I'm also wondering if we could perform better with SSL, if we cache the SSLContext and SSLSocketFactory. Currently, every data connection creates the SSLContext (even though the context parameters are the same) and gets the SocketFacotry from the context. Instead, we should create the SSLContext and SSLSocketFactory once per each SslConfiguration and reuse it. Obviously, this reduces the unnecessary object creation and eliminates the unnecessary method calls and context initialization. I've made some changes locally and things seem to be working fine. If you think we should apply this suggested change, I can post the patch for review. Basically, the changes we would need are: Add the following new method to the SslConfiguration interface - SSLSocketFactory getSocketFactory() throws GeneralSecurityException; Implement the above method method in the DefaultSslConfiguration. When constructing the DefaultSslConfiguration, create the SSLContext and an SSLSocketFactory and save them as members. Then when we need a SSLSocket, we simply call SSLConfiguration.getSocketFactory() which returns the pre-created socket factory. I know we may not notice much time difference with this change, but every little things add up, especially under high loads. Let me know what you think. Regards, Sai Pullabhotla www.jMethods.com On Wed, Aug 5, 2009 at 10:05 AM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: I'm not sure, I think it should go to the main trunk as well. Sai Pullabhotla www.jMethods.com On Wed, Aug 5, 2009 at 9:31 AM, Niklas Gustavssonnik...@protocol7.com wrote: On Wed, Aug 5, 2009 at 2:41 PM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: I also have another question around the same code...Should we be checking the remote address and make sure it matches with the IP address of the remote host on the control connection. If we do not do this check, it is possible for a hacker to connect to this port before the original client and may gain access to the data? I know it is not very easy to do this, but just in case. What do you think? I think this makes sense. We already do the logically same for active connections. Probably only should apply this to the 1.1.X (trunk) code, right? /niklas
Re: [vysper][pubsub] GSoC final weeks
On Wed, Aug 5, 2009 at 8:57 PM, Michael Jakljakl.mich...@gmail.com wrote: How shall we cope with the special smack libs? It seems that the required smack lib is from the development branch. For reference the URL again: http://github.com/squaremo/smackx-pubsub/tree/master From sampling some of the source files, look like it's ASL 2.0 in which case we can use it, right? /niklas
Re: FTPS with passive mode is slow
On Wed, Aug 5, 2009 at 5:05 PM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: I'm not sure, I think it should go to the main trunk as well. Trunk is 1.1.X so we're saying the same thing :-). I don't think it should go into 1.0.x. /niklas
Re: FTPS with passive mode is slow
On Wed, Aug 5, 2009 at 10:01 PM, Sai Pullabhotlasai.pullabho...@jmethods.com wrote: [snip] I know we may not notice much time difference with this change, but every little things add up, especially under high loads. Did you see any performance improvements in your local copy? Anyways, I think this makes sense, again for 1.1.X. /niklas
[FtpServer] Contributors List updates
Niklas, Two names (David and Sai) are missing from Contributors List. -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
[MINA] Codec Repository Page
Folks, I have created a Codec Repository page, capturing MINA based protocol codec. The link is http://cwiki.apache.org/confluence/display/MINA/Codec+Repository It's far from complete. The purpose of this page is to list all the known MINA based Codec. MINA users shall find it useful while implementing their own codecs or reuse the existing ones if possible. I haven't linked it from main page. Wanted community opinion on the same before linking it. Any suggestion? -- thanks ashish
