Support for anonymous connections

[GoogleCodeExporter]

Currently the SCTP library does not support dynamic anonymous connections.  To 
incorporate this functionality into the Mobicents Diameter stack this 
functionality is required.

After having a good look at this we think that the best way to extend the SCTP 
library to allow for anonymous client connections is as follows:

    Create a ServerListener framework where the SCTP library can inform an application if an anonymous remote incoming connection has been received - it is not compulsory to add this listener when using an SCTP server.  If it is not added then all anonymous connections will be ignored.
    Allow serverAssociation of 0.0.0.0:0 to be added as wildcard (edit ManagementImpl.java to allow port of 0)
    In SelectorThread.java - doAccept - If there is an association with 0.0.0.0:0 and an attached serverListener then we trigger a newRemoteConnection event on the ServerListener  and pass all the necessary information to the calling application.  The application can then decide whether to ignore and close the socket or create and add a new serverAssociation and Listener for this and attach to the socket. 
    Note that several params had to be made public to allow the calling application to create a new association and attach to the socket - including the Selector parameter in SelectorThread.java and setSocketChannel method in AssocationImpl.java,

This may sound a little clumsy - but because the AssociationListener class can 
only be instantiated and added from the calling application we think this is 
the cleanest option - and so far it seems to work!

Original mail thread is at:
https://groups.google.com/group/mobicents-public/browse_thread/thread/ddb1d3c31d
b62c0a?pli=1

Original issue is with Diameter project at:
http://code.google.com/p/mobicents/issues/detail?id=3056

Patch is attached.

Original issue reported on code.google.com by richgood...@gmail.com on 11 Jun 2012 at 3:41

Attachments:

• sctp-1.0.0.CR3_added_anonymous_connection_support.diff

[GoogleCodeExporter]

Issue 1 has been merged into this issue.

Original comment by amit.bha...@gmail.com on 11 Jun 2012 at 3:43

[GoogleCodeExporter]

Updated patch attached.  Initial diff did not include new file 
ServerListener.java

Original comment by richard....@smilecoms.com on 8 Aug 2012 at 9:35

Attachments:

• sctp-1.0.0.CR3_added_anonymous_connection_support.diff

[GoogleCodeExporter]

Attached is an updated patch that now also includes a basic Junit test for this 
new feature.

Original comment by richard....@smilecoms.com on 10 Aug 2012 at 1:54

Attachments:

• sctp_1.0.0.FINAL_with_sctp_and_junit_test

[GoogleCodeExporter]

Hello!

I have some remarks for SCTP stack ant this patch.

1. If you revise the SelectorThread.doAccept() method you can see that if we 
configured 
- two Servers with names "serv1" and "serv2" with local ports 1 and 2
- two server Associations with names "ass1" and "ass2" with peer ports 1 and 2 
and peer addresses addr1 and addr2
then when we have incoming SCTP socket from peer port 1 and peer address addr1 
to local port 2 we will establish connection to the association "ass1" but we 
should not do it because association "ass1" does not refer to server "serv2" 
(it refers to "serv2").
This occues also without the patch

2. Is SCTP stack is configured to receive both anonymous and nonanonymous 
connections and the anonymous asociation is configured first in the 
associations's list all incoming connections will be accepted as anonymous even 
if they are really nonanonymous.

3. We can not configure two anonymous servers (with different listerning ports) 
because we can not configure two associations with the peer port=0 peer 
address="0.0.0.0"

4.The most important from my point of view is that in this approach we will 
have only server that accepts incoming connections and gives 
AbstractSelectableChannel to a ServerEventListener. ServerEventListener should 
then itself manage to send and recieve data and close a connection. And we will 
not be able to use for example Association.send(PayloadData payloadData) and 
AssociationListener.onPayload(Association association, PayloadData 
payloadData). An anonymous association can carry several anonymous connections 
at the same time.

Original comment by serg.vet...@gmail.com on 12 Aug 2012 at 11:09

[GoogleCodeExporter]

Hi,

1. Agree with this.  

It seems that doAccept runs through all the socketAddresses:

for (SocketAddress sockAdd : socAddresses) {

And then runs through all the associations for each socketAddress instead of 
only running through the associations "associated" with that socket address:

FastMap<String, Association> associations = this.management.associations;
for (FastMap.Entry<String, Association> n = associations.head(), end = 
associations.tail(); (n = n.getNext()) != end && !provisioned;) {

Could solve this by adding in a check when running through the associations 
that this association is "associated" with the socket channel - by comparing 
the host address and port of the association to the socket channel.

What do you think?  I am not familiar enough with the entire architecture to be 
sure that this won't affect anything else like multihoming...

Original comment by richard....@smilecoms.com on 13 Aug 2012 at 8:53

[GoogleCodeExporter]

2.  This is linked to your first Q.  Because of the previous bug you mentioned, 
if  serverAssociation is added with 0, "0.0.0.0" first it will be picked up in 
doAccept by all socketAddresses (not just the server that it is associated 
with).

e.g. if we add "serv1", local port 1, and addServerAssociation for "serv1" with 
0,"0.0.0.0" and then we add "serv2", local port 2, and addServerAssociation for 
"serv2" with 3868,"10.0.1.1".  "serv2" will also accept anonymous connections.

If the bug in Q1 is fixed then only a server with serverAssociation 0, 
"0.0.0.0" will accept anonymous connections

Original comment by richard....@smilecoms.com on 13 Aug 2012 at 8:58

[GoogleCodeExporter]

3.  Also a problem.  Not sure how to solve this one.  Any suggestions?  

Why does the limitation exist that you cannot have multiple server associations 
with same peer address and peer port?  

I would think that the limitation should be that you cannot have multiple 
server associations with same peer address and same peer port PER SERVER.

Original comment by richard....@smilecoms.com on 13 Aug 2012 at 9:09

[GoogleCodeExporter]

4.  Agreed that the power is passed to ServerEventListener and Association.send 
cannot be used for the "anonymous" ServerAssociationListener.


The idea is that for each new Remote Connection caught by ServerEventListener a 
new Server Association is added and this used is to send data.

It may seem clumsy but it was the cleanest approach we could come up with.  
Open to any suggestions.

Original comment by richard....@smilecoms.com on 13 Aug 2012 at 9:16

[GoogleCodeExporter]

Had chat with Sergey

Summary :
1) Exposing Sockets to Application is not good idea. It kills the whole purpose 
of SCTP project. Application will have to manage the life cycle of Socket which 
is again not the intent. 
2) Server interface should configurable parameter to allow anonymous 
connection. This parameter is passed while creating Server.  
3) ServerListener only exposes the anonymous Association giving chance to 
Application to register AssociationListener. Anonymous Associations will not be 
persisted. 


Chat :


Sergey:  ok
I have updated  Issue 2:         Support for anonymous connections
(gave some questions)
The questin #4 is the most important for me
4.The most important from my point of view is that in this approach we will 
have only server that accepts incoming connections and gives 
AbstractSelectableChannel to a ServerEventListener. ServerEventListener should 
then itself manage to send and recieve data and close a connection. And we will 
not be able to use for example Association.send(PayloadData payloadData) and 
AssociationListener.onPayload(Association association, PayloadData 
payloadData). An anonymous association can carry several anonymous connections 
at the same time.
This is all about SCTP update for anonymous connections
WDYT?
 me:  let me see
 Sergey:  ok
 Sent at 2:42 PM on Monday
 me:  ok I spent time looking at it
1) I agree that exposing internal sockets is not good idea
2) I think we can redesign
such that server can be setup for anonymous connections
and when ever it gets one it allows Application to register listener
 Sent at 2:58 PM on Monday
 me:  for example
 Sergey:  "when ever it gets one it allows Application to register listener" - do not understand
 me:  ok hold
public interface ServerListener {

       public AssociationListener onNewRemoteConnection(String peerAddress, int peerPort);
}
this is new api
so if server is configured for accepting anonymous connections
it calls back application
and if application gives back AssociationListener, management will add new 
server side association and register passed listener
if AssociationListener is null, means application is not interested and close 
the connection
wdyt?
 Sergey:  Amit, the root problem is that we configure ONE assiciation for ALL incoming SCTP calls
 me:  or may be 
public interface ServerListener {

       public AssociationListener onNewRemoteConnection(String serverName, String peerAddress, int peerPort);
}
 Sent at 3:03 PM on Monday
 Sergey:  I guess we can configure some "anonymous" server that listern a sctp port
and after an incoming SCTP connection we will create a special type "anonymous" 
connection
that will be stored at the separate list at the management
 me:  hmm so you mean these anonymous connection/association will not be persisted either
 Sergey:  May be we can give that Association in ServerListener
If we want to use Association.send(PayloadData payloadData)
we should have a separate anonymous association for each connection
If you agree with my doubts
we must change interafce first of all
 me:  yes I do agree
but I think we can modify existing Association.java
to include one more parameter
isAnonymous
and Server.java also has setAnonymosu
 Sergey:  agree, but these updates is not enouph
 me:  right, need changes in SelectorThread.doAccept() as well
 Sent at 3:12 PM on Monday
 Sergey:  so if we want to listern for anonymous connections we should configure only a anonymous server (and should not create anonymous association), agree?
 me:  yes
 Sergey:  At such servers the max count of concurent possible connections can be configured
 me:  yes
 Sergey:  ok

Original comment by amit.bha...@gmail.com on 13 Aug 2012 at 9:58

[GoogleCodeExporter]

Ok fair enough - let me know when you have done the modifications and I can 
build into Diameter and test.

Original comment by richard....@smilecoms.com on 13 Aug 2012 at 10:59

[GoogleCodeExporter]

Hello!

I am trying to implement an interface for anonymous connections.

1. So I did:
- AssociationType - added a new type - ANONYMOUS_SERVER

- Association - added:
    /**
     * Use this method only for accepting anonymous connections
     * from the ServerListener.onNewRemoteConnection() invoking
     * 
     * @param associationListener
     * @throws Exception
     */
    public void acceptAnonymousAssociation(AssociationListener associationListener) throws Exception;

    /**
     * Use this method only for rejecting anonymous connections
     * from the ServerListener.onNewRemoteConnection() invoking
     */
    public void rejectAnonymousAssociation();

    /**
     * Stop the anonymous association. The connection will be closed and we will not reuse this association
     * This can be applied only for anonymous association, other associations must be stopped by 
     * Management.stopAssociation(String assocName) 
     * 
     * @throws Exception
     */
    public void stopAnonymousAssociation() throws Exception;

- public interface ServerListener {
    public void onNewRemoteConnection(Server server, Association association);
}
This is invoked when an anonimous connection is coming. "server" defines the 
listerning server. "association" a created ANONYMOUS_SERVER association. Use 
association.getPeerAddress() and association.getPeerPort() to obtain a peer 
address/post.

- Management: 
  - in the method addServer() added two parameters:
    - boolean acceptAnonymousConnections,
    - int maxConcurrentConnectionsCount
  - added methods
    - public ServerListener getServerListener();
    - public void setServerListener(ServerListener serverListener);

- Server: added methods:
  - public boolean isAcceptAnonymousConnections();
  - public int getMaxConcurrentConnectionsCount();
  - public void setMaxConcurrentConnectionsCount(int val);

2. If you have to accept anonymous connections you should:
- create a Server with acceptAnonymousConnections==true
- do not create any Associations
- register ServerListener in a Management (not in Server as was in the last 
patch)
- start a Server
- wait for ServerListener.onNewRemoteConnection() invocations
- in ServerListener.onNewRemoteConnection() invoke we can check peer address 
and port and other conditions and:
  - Association.acceptAnonymousAssociation() or
  - Association.rejectAnonymousAssociation()
- for any incoming connection a new Association with a type ANONYMOUS_SERVER is 
created
- such associations are not added into ManagementImpl.associations, So they are 
not serialized into a config files and are absent in 
Management.getAssociations()
- a user can write/read data as a usual association
- to close an Association use Association.stopAnonymousAssociation()

3. There is a question for me if we should keep all created anonymous 
associations in the a separate collection (and remove them from it after socket 
closing). The profit of this can be:
- we can have a total count of active concurent connections and do not accept 
incoming connections whet the current count>=maxConcurrentConnectionsCount (now 
I do not know another way to do it)
- we can force closing all active connections when Server stopping
- we can give this list to a user. But this list will not thread safe
we can add an Association into this list when we make AssociationImpl.up=true 
and remove when we make AssociationImpl.up=false

4 I will commit my update into an "anonymous" branch of SCTP project soon 

Any comments are welcome

Original comment by serg.vet...@gmail.com on 15 Aug 2012 at 4:20

• Changed state: Started

[GoogleCodeExporter]

I have commited the draft verion of code

Original comment by serg.vet...@gmail.com on 15 Aug 2012 at 4:40

[GoogleCodeExporter]

Hello!

1. As if SCTP project supports anonymous Server association I added support for 
Client association with unspecified local port.
In Management.addAssociation() use hostPort==0. In this case when outgoing 
connection establishing a vacant local port we used.

2. ServerImpl now has a list of active anonymous connections: 
ServerImpl.anonymAssociations. This helps of checking max incoming anonymous 
connections count and rejecting connections if this limit is reached.
- Should we make this anonymAssociations list public?
- Should we stop all active anonymous associations when Server stopping?

3. I have implemented a unit test AnonymousConnectionTest and remove some bugs. 
This test passes.

4. I have commited last changes in the "anonymous" branch. Any remarks and bug 
reposts are welcome.

Original comment by serg.vet...@gmail.com on 16 Aug 2012 at 11:25

[GoogleCodeExporter]

Hi Sergey,

I reviewed the code. Looks better now.

>>- Should we make this anonymAssociations list public?
we can. the method can return unmodifialble List so user doesn't try to remove 
anonymous association from list. See FastList.unmodifiable() 


>>- Should we stop all active anonymous associations when Server stopping?
Yes

Original comment by amit.bha...@gmail.com on 16 Aug 2012 at 7:46

[GoogleCodeExporter]

Looks good, nice work.  I will implement the new API and test with Diameter 
stack.  Should give feedback sometime next week.

Original comment by richard....@smilecoms.com on 17 Aug 2012 at 2:06

[GoogleCodeExporter]

Hello!

I made little update and merged the update into a master branch.

Original comment by serg.vet...@gmail.com on 20 Aug 2012 at 11:26

[GoogleCodeExporter]

Fixed and committed

Original comment by amit.bha...@gmail.com on 25 Sep 2012 at 3:24

• Changed state: Fixed