(no subject)

Hello everybody,

right now I am implementing a prototype registrar server for Dr.  
Tuexen. I'm doing this in a follow up to my bachelor thesis, in which  
I started working on that project.

The server is still missing a lot of features like takeover  
functionality and asap interfaces to the pool elements and pool  
users. During my studies of the definition documents I found some  
issues I have some questions about:

The first issue is about sctp and the lifetime of sctp associations.  
Do assocs between two registrar servers exist for the complete  
lifetime of both servers, only dying, when one server dies, or can  
they be created and shutdown when necesary?

Next question: The ENRP draft says, there are point-to-point messages  
and announcments. Where is the difference? Are announcemennts ment  
for everybody like presence mesages and the takeover stuff? Or are  
announcements generally all messages that are sent via the multicast  
group? I think it wouldn't make sense to send some of the bigger  
messages via multicast, like responses to peer list requests or  
handle table requests. That would create a lot of traffic on the  
multicast group and all associated peers.

The BSD SocketApi describes a neat feature, namely a "send-to-all- 
assocs" mode via a SCTP_SEND_ALL flag to the send call. Sounds very  
nice and would make life sometimes easier. Problem: I can not put in  
the correct receiver server ID for each peer since its a send-to-all  
message. The draft only says, that the ID should be set to 0 when  
sendiang via the multicast group. What should I do?

In 3.1 3D the enrp draft says that each message sent to the multicast  
group must be sent as a copy to each peer by an sctp point-to-point  
assoc. Why just not ignore everything from the multicast group and  
wait for the SCTP copy, except for presence messaged of new registrar  
servers? Multicast messages could be spoofed, and i think it might be  
tricky to establish the nedded security mechanisms like TLS for  
multicast UDP.

Right now, I am spending some time on implementing the takeover  
functionality. When two or more registrar initiate a takeover, the  
server with the lowest ID will have to continue it, all others have  
to cancel it. In a scenario, where some registrars may die sometimes,  
and get taken over, the server with the lowest id will end up with a  
lot of pool elements to oversee.
This leads to a question: Should it be possible for registrar servers  
to delegate some of their pool elements to other registrars to  
balance out the overall load?
Is there a timeout for the takeover proscess? What happens if it  
times out and not all peers have answeres?

In a follow up i thought about some network topologies: There are no  
rules to control how pool users and pool elements choose a registrar  
to get either a pool handle resolution or a home server to register  
with. If one registrar server is in the topologie closer to the pool  
users or elements, he will have shorter response times and thus  
getting chosed more frequently. Also there is no rule to choose the  
registrar with, for example, the lowest load.
Right now, the enrp draft suggests that all registrar servers must be  
able to see each other, since there is no possibility to forward  
registration information when multicast is disabled.

Right now these are just some ideas, they still need and will be  
tested, when my implementation reaches the necesarry level of  
completness.

Best regards

	Frank Volkmer