[freenet-support] rfi: FCP API for 0.7
Anything you can say on this or provide me with some pointers to where I might be able to find some answers? Not necessarily specs, but something that will give a bit of confidence things will be allright or how things API related will progress? Thank you "It would be nice indeed and a positive sign if something was said about what to expect on the API. It will not be something esoteric, it will be like what it is now as seen from a functional level, I guess. Maybe the messages being exchanged will have a different format but that will not cause much trouble. Just make sure the FCP parts are properly isolated and the distance will be relatively short, I hope." -- Vanessa [EMAIL PROTECTED] -- http://www.fastmail.fm - The way an email service should be ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] rfi: FCP API for 0.7
Anything you can say on this or provide me with some pointers to where I might be able to find some answers? Not necessarily specs, but something that will give a bit of confidence things will be allright or how things API related will progress? Thank you "It would be nice indeed and a positive sign if something was said about what to expect on the API. It will not be something esoteric, it will be like what it is now as seen from a functional level, I guess. Maybe the messages being exchanged will have a different format but that will not cause much trouble. Just make sure the FCP parts are properly isolated and the distance will be relatively short, I hope." -- Vanessa vanessavasquez at fastmail.fm -- http://www.fastmail.fm - The way an email service should be
[freenet-support] cause of Got a trailer chunk ahead of our time!
As for this one: Got a trailer chunk ahead of our time! It seems this is caused by a reestablished session (with that I refer to a connection between peers) where a packet from the previous session with the same peer is considered part of the current session (mux mess). This sometimes causes almost all sessions to be closed and sometimes it is more than one packets from the previous session. This applies to both an inbound session that is closed and opened again by the same peer soon after and an outbound session that is closed and opened again to the same peer soon after. Maybe putting in a longer delay than the constant I saw would be a workable workaround. Is it delayed finalization or some state that remains after a session got closed? -- Vanessa [EMAIL PROTECTED] -- http://www.fastmail.fm - Send your email first class ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] cause of Got a trailer chunk ahead of our time!
As for this one: Got a trailer chunk ahead of our time! It seems this is caused by a reestablished session (with that I refer to a connection between peers) where a packet from the previous session with the same peer is considered part of the current session (mux mess). This sometimes causes almost all sessions to be closed and sometimes it is more than one packets from the previous session. This applies to both an inbound session that is closed and opened again by the same peer soon after and an outbound session that is closed and opened again to the same peer soon after. Maybe putting in a longer delay than the constant I saw would be a workable workaround. Is it delayed finalization or some state that remains after a session got closed? -- Vanessa vanessavasquez at fastmail.fm -- http://www.fastmail.fm - Send your email first class
[freenet-support] (no subject)
I hope you will make the 0.7 version strong enough to not have a problem with massive number incoming connections. The i/o at muxing level (I have seen it, I will spare you my critique, it has given you enough trouble, I can see) in the current 5.something stable version is not able to stand against 60 incoming connection attempts per 90 seconds on average. I modded the node so that it is able to stand against it and get healthy connection lfe times. If you are interested in that mod you should let me know. Same goes for feeding FuqidOnSteroids the number of inbound and outbound connections (easy). ShitList is a bit harder and not complete yet and help would be appreciated. -- Vanessa [EMAIL PROTECTED] -- http://www.fastmail.fm - Access all of your messages and folders wherever you are ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] (no subject)
I hope you will make the 0.7 version strong enough to not have a problem with massive number incoming connections. The i/o at muxing level (I have seen it, I will spare you my critique, it has given you enough trouble, I can see) in the current 5.something stable version is not able to stand against 60 incoming connection attempts per 90 seconds on average. I modded the node so that it is able to stand against it and get healthy connection lfe times. If you are interested in that mod you should let me know. Same goes for feeding FuqidOnSteroids the number of inbound and outbound connections (easy). ShitList is a bit harder and not complete yet and help would be appreciated. -- Vanessa vanessavasquez at fastmail.fm -- http://www.fastmail.fm - Access all of your messages and folders wherever you are
