Re: [vysper] Sending a message to all connected resources
On Sat, Mar 13, 2010 at 19:15, Jean-Sebastien Delfino jsdelf...@apache.org wrote: Bernd Fondermann wrote: On Thu, Mar 11, 2010 at 10:31, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Thu, Mar 11, 2010 at 09:51, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Thu, Mar 11, 2010 at 09:06, Jean-Sebastien Delfino jsdelf...@apache.org wrote: With ejabberd and gtalk (and IIRC jabberd too), if I send a message to j...@foo.com for example, and jdoe is listening through multiple client resources, like j...@foo.com/desktop, j...@foo.com/laptop, j...@foo.com/phone, he'll get a copy of the message on each resource. From what I can see in my test environment, Vysper seems to behave differently and only delivers the message to one of the connected resources. Is there a way to send a message to all connected resources like the other servers do? or did I miss anything in the way I've constructed the XMPPServer [1]? Looking at the code, this is the way it's implemented. However, you could send a message type=headline and this would go to all resources. I've checked the XMPP specs: XMPP Core - RFC 3920 Section 10.5 [2] says 'should deliver the stanza to at least one of the connected resources' XMPP IM - RFC 3921 Section 11.1 [3] says 'MAY choose between them or MAY deliver the message to all such resources' Then XEP-0259 [4] introduces a protocol extension allowing device resources to control which one should receive the messages. So, I'm not an XMPP expert... but unless Vysper implements XEP-0259 -- or another relevant XMPP extension from this spec maze :) -- I think it would make sense to send the message to all connected resources (unless they have indicated a negative priority, as described in [3].) ... unless of course you send to a resource directly. Thoughts? I'm undecided. I'll go and figure. see http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-05.html#rules-barejid-resource-message and VYSPER-179 We really have the choice. Means we should give users the choice and make it configurable. After implementing the functionality, of course :-) Also, what is not working properly right now is how the prio resolution tie is resolved. I'll have a look. In trunk, should now work as you suggested. Bernd Thanks, it works! until I disconnect and reconnect some of the clients. That may be a different issue, but it looks client sessions are not removed from the list of delivery targets when the clients disconnect. From the log: 09:58:05,347 | WARN | org.apache.vysper.xmpp.delivery.inbound.DeliveringInboundStanzaRelay | multiplexing: 6 sessions will be processing message.body.hey shows 6 sessions, although I only have 2 clients connected right now. Once I disconnect a client messages are not delivered anymore to all the other connected clients. I'll investigate more if I find some time over the weekend and post what I find here... Thanks for reporting this! I can reproduce and will commit a simple fix as soon as possible. Bernd
[jira] Commented: (VYSPER-95) Multi-module build for Vysper
[ https://issues.apache.org/jira/browse/VYSPER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846846#action_12846846 ] Bernd Fondermann commented on VYSPER-95: Niklas, isn't this largely resolved? Multi-module build for Vysper - Key: VYSPER-95 URL: https://issues.apache.org/jira/browse/VYSPER-95 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson The Vysper code base is already quite big and adding new XEPs will only make it bigger. We should therefore look into breaking Vysper into modules, possibly with bigger XEPs going into their own module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (VYSPER-95) Multi-module build for Vysper
[ https://issues.apache.org/jira/browse/VYSPER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-95. --- Resolution: Fixed It sure is, closing. Multi-module build for Vysper - Key: VYSPER-95 URL: https://issues.apache.org/jira/browse/VYSPER-95 Project: VYSPER Issue Type: Improvement Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson The Vysper code base is already quite big and adding new XEPs will only make it bigger. We should therefore look into breaking Vysper into modules, possibly with bigger XEPs going into their own module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Start using repository.apache.org for releases
On Tue, Mar 16, 2010 at 10:43 AM, Niklas Gustavsson nik...@protocol7.com wrote: [X] +1, do it /niklas
[RESULT][VOTE] Start using repository.apache.org for releases
On Tue, Mar 16, 2010 at 10:43 AM, Niklas Gustavsson nik...@protocol7.com wrote: Since no-one objected on the discussion thread, here's the formal vote to move our releases to repository.apache.org. This vote passes with 5 +1 votes. I'll ask the repository guys to set us up. Thanks for voting! /niklas
Re: Black/White List in FTP Server
Attached is the alpha release ;) for the black/white lists for your review. This patch is created from the trunk. I briefly tested this as a stand-alone server using spring config as well as programmatically configuring the server with a custom IP Filter. I updated the spring config/parser to support old style blacklist element or the new ip-filter element. If both elements are used, it raises an error. Both elements use the new IP Filter. Keep in mind that I still may have to do some tweaking and cleanup, but thought I should get this out to you guys for review so we can tweak it as needed. I appreciate any feedback. Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:18 AM, Niklas Gustavsson nik...@protocol7.com wrote: On Tue, Mar 16, 2010 at 1:05 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: Does this mean you want to wait until Mina 3.0, or should we start working on the FTP Server right away and share relevant code with MINA? I think we can start right away and copy the code upstream until we move FtpServer to MINA 3.0. /niklas
Re: Black/White List in FTP Server
On Thu, Mar 18, 2010 at 7:20 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: Attached is the alpha release ;) for the black/white lists for your review. Create a JIRA issue and attach it there. Mailing lists strip attachments :-) /niklas
[jira] Created: (FTPSERVER-357) Implement IP Filtering based on black or white list
Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-357: -- Attachment: ftpserver-ipfilter.patch Please review this and provide your feedback. Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Attachments: ftpserver-ipfilter.patch Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Black/White List in FTP Server
Done. Regards, Sai Pullabhotla On Thu, Mar 18, 2010 at 1:32 PM, Niklas Gustavsson nik...@protocol7.com wrote: On Thu, Mar 18, 2010 at 7:20 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: Attached is the alpha release ;) for the black/white lists for your review. Create a JIRA issue and attach it there. Mailing lists strip attachments :-) /niklas
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847084#action_12847084 ] Niklas Gustavsson commented on FTPSERVER-357: - Some comments on the patch: * We need to do this change without removing method in the public API, otherwise it needs to wait until a future 2.0. Would be good if we can get it into 1.1 * Patch includes lots of changes to AbstractListener, is that part of this change (perhaps only whitespace changes)? * Patch includes changes to NativeFileSystemView which does not belong in this patch * //TODO what's the good exception to throw from here? - FtpServerConfigurationException * Would it be a good idea to make DefaultIpFilter immutable? Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Attachments: ftpserver-ipfilter.patch Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vysper] Sending a message to all connected resources
Done. Bernd Bernd Fondermann wrote: On Sat, Mar 13, 2010 at 19:15, Jean-Sebastien Delfino jsdelf...@apache.org wrote: Bernd Fondermann wrote: On Thu, Mar 11, 2010 at 10:31, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Thu, Mar 11, 2010 at 09:51, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Thu, Mar 11, 2010 at 09:06, Jean-Sebastien Delfino jsdelf...@apache.org wrote: With ejabberd and gtalk (and IIRC jabberd too), if I send a message to j...@foo.com for example, and jdoe is listening through multiple client resources, like j...@foo.com/desktop, j...@foo.com/laptop, j...@foo.com/phone, he'll get a copy of the message on each resource. From what I can see in my test environment, Vysper seems to behave differently and only delivers the message to one of the connected resources. Is there a way to send a message to all connected resources like the other servers do? or did I miss anything in the way I've constructed the XMPPServer [1]? Looking at the code, this is the way it's implemented. However, you could send a message type=headline and this would go to all resources. I've checked the XMPP specs: XMPP Core - RFC 3920 Section 10.5 [2] says 'should deliver the stanza to at least one of the connected resources' XMPP IM - RFC 3921 Section 11.1 [3] says 'MAY choose between them or MAY deliver the message to all such resources' Then XEP-0259 [4] introduces a protocol extension allowing device resources to control which one should receive the messages. So, I'm not an XMPP expert... but unless Vysper implements XEP-0259 -- or another relevant XMPP extension from this spec maze :) -- I think it would make sense to send the message to all connected resources (unless they have indicated a negative priority, as described in [3].) ... unless of course you send to a resource directly. Thoughts? I'm undecided. I'll go and figure. see http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-05.html#rules-barejid-resource-message and VYSPER-179 We really have the choice. Means we should give users the choice and make it configurable. After implementing the functionality, of course :-) Also, what is not working properly right now is how the prio resolution tie is resolved. I'll have a look. In trunk, should now work as you suggested. Bernd Thanks, it works! until I disconnect and reconnect some of the clients. That may be a different issue, but it looks client sessions are not removed from the list of delivery targets when the clients disconnect. From the log: 09:58:05,347 | WARN | org.apache.vysper.xmpp.delivery.inbound.DeliveringInboundStanzaRelay | multiplexing: 6 sessions will be processing message.body.hey shows 6 sessions, although I only have 2 clients connected right now. Once I disconnect a client messages are not delivered anymore to all the other connected clients. I'll investigate more if I find some time over the weekend and post what I find here... Thanks for reporting this! I can reproduce and will commit a simple fix as soon as possible. Bernd
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847102#action_12847102 ] Sai Pullabhotla commented on FTPSERVER-357: --- Oh, BTW, I missed an else block in the DefaultIpFilter.add(String) method which should have been there to filter a specific IP address. It's in now in my local copy. Just an FYI. Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Attachments: ftpserver-ipfilter.patch Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847103#action_12847103 ] Sai Pullabhotla commented on FTPSERVER-357: --- I think I can get it to work with the old methods and constructors in the factory classes. Just wanted to get it going so, the quickest way was to remove/change signatures. I will look into it some more and let you know. I will double check the AbstractListener and see if I formatted the whole class. If I did, I will re-apply may changes to the version from trunk. Yeah, the FileSystem class changes were an accidental inclusion in the patch. I might open a new thread on this as I think it would be nice to have some of these member variables accessible in subclasses. It was a while ago I was playing with a subclass and needed those. I'll have to rewind and figure out what I was doing then. I don't think the DefaultIpFilter needs to be immutable. The class is extended from a Set that makes a copy of the Set on every change to the Set, so it is safe to modify the Set while an iterator is iterating over the items. Of course, I stole the idea from the existing filter in MINA. If everything else looks okay, and if you think the package/class names are good as they are, I will go ahead and try to wrap this up this week. Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Attachments: ftpserver-ipfilter.patch Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847107#action_12847107 ] Sai Pullabhotla commented on FTPSERVER-357: --- I think I can get it to work with the old methods and constructors in the factory classes. Just wanted to get it going so, the quickest way was to remove/change signatures. I will look into it some more and let you know. I will double check the AbstractListener and see if I formatted the whole class. If I did, I will re-apply may changes to the version from trunk. Yeah, the FileSystem class changes were an accidental inclusion in the patch. I might open a new thread on this as I think it would be nice to have some of these member variables accessible in subclasses. It was a while ago I was playing with a subclass and needed those. I'll have to rewind and figure out what I was doing then. I don't think the DefaultIpFilter needs to be immutable. The class is extended from a Set that makes a copy of the Set on every change to the Set, so it is safe to modify the Set while an iterator is iterating over the items. Of course, I stole the idea from the existing filter in MINA. If everything else looks okay, and if you think the package/class names are good as they are, I will go ahead and try to wrap this up this week. Regards, Sai Pullabhotla On Thu, Mar 18, 2010 at 2:54 PM, Niklas Gustavsson (JIRA) Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Attachments: ftpserver-ipfilter.patch Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847115#action_12847115 ] Niklas Gustavsson commented on FTPSERVER-357: - Yes, besides those details (breaking the API is a blocker for 1.1), I think it looks good! Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Attachments: ftpserver-ipfilter.patch Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
