[reSIProcate] Question concerning resiprocate-1.5

neil.young neil.young at freenet.de
Fri Sep 11 11:15:53 CDT 2009


Wow, you can be proud of your "memory". It would be very interesting to 
know, how you synchronize such a big team (because I'm usually a "lone 
wolf").

We currently have some issues (under Windows, VS2008) with the stream 
tellp behavior, but right now I got the info, it is running now. I was 
asking for rutil lately, because we appeared problems with  DataBuffer, 
derived from std::streambuf. We had to derive it from stringbuf in order 
to make seek and tellp run, otherwise tellp always returns -1 and the 
fail bit is set... Strange...

Anyway.

First I would like to ask for a very basic protocol issue, from the very 
first startup. If a node acts as a bootstrap node, it immediately fires 
its nodeID once it gets connected. I have looked into several versions 
of the draft, but found no reason for this behavior. It has always been 
pointed out, that - once a joining node enters the ring - always the 
joining node sends its nodeID to the bootstrap node. Is there any reason 
for the different behavior?

Do you remember, what version of RELOAD was current, the time you dealt 
with it?

Regards



Adam Roach schrieb:
> The code was written by most of the primary resip contributors: Cullen 
> Jennings, Eric Rescorla, Robert Sparks, Derek MacDonald, Jason Fischl, 
> Scott Godin, Duane Storey,  Alan Hawrylyshen, and me (forgive my 
> memory if I've left someone out). This might help you figure out who 
> is potentially capable of answering questions you have -- but keep in 
> mind that we did this a long time ago. For example, my memory on any 
> of this is very rusty.
>
>         AbstractValue.hxx: derek sgodin
>            ArrayValue.hxx: derek sgodin duanestorey
>         BatchMessages.cxx: derek
>         BatchMessages.hxx: derek fluffy
>             Candidate.hxx: ekr adam sgodin duanestorey
>         CertDoneEvent.hxx: derek fluffy
>         ChordTopology.cxx: ekr derek jason fluffy sgodin bcampen
>         ChordTopology.hxx: ekr jason fluffy sgodin
>           ChordUpdate.cxx: sgodin duanestorey
>           ChordUpdate.hxx: duanestorey
>               Connect.cxx: alan jason duanestorey
>               Connect.hxx: ekr sgodin duanestorey
>           ConnectBase.cxx: sgodin duanestorey
>           ConnectBase.hxx: sgodin duanestorey
>         DataSpecifier.hxx: derek jason
>         DestinationId.cxx: jason sgodin duanestorey
>         DestinationId.hxx: jason
>       DictionaryValue.hxx: derek sgodin
>            Dispatcher.cxx: derek jason duanestorey
>            Dispatcher.hxx: derek jason
>                 Event.hxx: derek jason fluffy
>         EventConsumer.hxx: derek jason fluffy sgodin
>     EventConsumerBase.hxx: derek
>          EventWrapper.hxx: ekr derek jason fluffy
>              FetchAns.hxx: derek jason
>             FetchKind.hxx: derek
>              FetchReq.hxx: derek jason
>                  Find.cxx: duanestorey
>                  Find.hxx: derek jason duanestorey
>                FlowId.cxx: derek
>                FlowId.hxx: adam derek sgodin
>       ForwardingLayer.cxx: ekr adam derek jason fluffy sgodin
>       ForwardingLayer.hxx: adam derek jason fluffy
>                  Join.cxx: jason sgodin duanestorey
>                  Join.hxx: alan jason sgodin duanestorey
>                 Leave.cxx: jason duanestorey
>                 Leave.hxx: alan derek jason duanestorey
>               Message.cxx: ekr adam derek jason fluffy sgodin bcampen 
> duanestorey
>               Message.hxx: ekr adam alan derek jason fluffy sgodin 
> duanestorey
>         MessageHelper.cxx: duanestorey
>         MessageHelper.hxx: duanestorey
>     MessageStructsGen.cxx: ekr
>     MessageStructsGen.hxx: ekr sgodin
>                NodeId.cxx: ekr adam jason fluffy sgodin
>                NodeId.hxx: adam jason fluffy sgodin
>              P2PStack.cxx: jason fluffy
>              P2PStack.hxx: jason fluffy
>          P2PSubsystem.cxx: sgodin
>          P2PSubsystem.hxx: derek sgodin
>           ParsingTest.cxx: ekr jason duanestorey
>              Postable.hxx: derek sgodin
>               Profile.hxx: ekr adam jason fluffy sgodin
>            ResourceId.cxx: jason sgodin duanestorey
>            ResourceId.hxx: jason sgodin duanestorey
>     SelectTransporter.cxx: ekr adam derek jason sgodin duanestorey
>     SelectTransporter.hxx: ekr adam jason sgodin
>              Signable.cxx: duanestorey
>              Signable.hxx: derek jason sgodin duanestorey
>      SignatureContext.cxx: ekr duanestorey
>      SignatureContext.hxx: ekr jason sgodin
>           SingleValue.hxx: derek sgodin
>              StoreAns.hxx: derek jason
>              StoreReq.hxx: derek jason
>              StoreSet.hxx: derek fluffy
>              TestMake.cxx: derek jason
>           TopologyAPI.cxx: ekr derek jason fluffy sgodin
>           TopologyAPI.hxx: ekr derek jason fluffy sgodin
>              TransApi.hxx: derek fluffy sgodin
> TransactionController.cxx: sgodin
> TransactionController.hxx: sgodin
>      TransactionState.cxx: sgodin
>      TransactionState.hxx: sgodin
>           Transporter.cxx: ekr adam jason sgodin
>           Transporter.hxx: ekr adam jason sgodin
>    TransporterMessage.cxx: adam jason sgodin
>    TransporterMessage.hxx: ekr adam jason fluffy sgodin
>                Update.cxx: jason duanestorey
>                Update.hxx: jason duanestorey
>              UserName.hxx: ekr fluffy sgodin
>                   p2p.hxx: ekr derek
>
> /a
>
> On 9/11/09 5:53 AM, Neil.Young wrote:
>> Hi again,
>>
>> is there still one of the old "hams" alive :) and open for some 
>> question concerning the current implementation of RELOAD?
>>
>> Thanks
>> Regards
>>
>>
>> Adam Roach schrieb:
>>> The rutil tree is used by just about every other part of resip. It 
>>> is well tested and stable.
>>>
>>> /a
>>>
>>> On 9/10/09 4:51 PM, neil.young wrote:
>>>> May I additionally ask for you opinion about the state of the 1.5 
>>>> rutil path? Is it stable? Or was it also part of the 2-3 days hack. 
>>>> If not, I could concentrate on P2P...
>>>>
>>>> Regards
>>>>
>>>>
>>>> Adam Roach schrieb:
>>>>> The p2p code is based on a fairly early version of the RELOAD 
>>>>> specification, and is incomplete. If you're interested in doing 
>>>>> work to bring it in line with the latest specification and/or 
>>>>> completing the missing components, you're on the right path.
>>>>>
>>>>> If you're trying to use it to build an application at this point 
>>>>> in time, you're going to be frustrated.
>>>>>
>>>>> /a
>>>>>
>>>>> On 09/10/2009 02:30 PM, neil.young wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to build the p2p branch of resiprocate-1.5. I could 
>>>>>> manage to successfully compile the files of the solution, but the 
>>>>>> link of the testconsole failed due to missing libs, namely 
>>>>>> p2p.lib and rutil.lib. After I added the libs, everything was fine.
>>>>>>
>>>>>> Known issue?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> resiprocate-devel mailing list
>>>>>> resiprocate-devel at resiprocate.org 
>>>>>> <mailto:resiprocate-devel at resiprocate.org>
>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel at resiprocate.org
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20090911/fa728a91/attachment.htm>


More information about the resiprocate-devel mailing list