On Thursday 25 Apr 2013 10:23:05 [email protected] wrote: > Hey Chetan, > > I started to implement a packet transport plugin that convert the data > portion of the packet before sending it off and before processing it after > it is received, as a part of "if I know coding" quiz. > > I have few questions regarding this and I thought you might be able to help > me with them. > > 1) From the point of view of a coder who wants to implement such a transport, > it is natural to inherit from UdpSocketHandler. However, my > understanding is that the transport plugins should be "pluggable" like > other plugins on freenet, i.e. user be able to easily enable and disable > them, to > reach this goal, is there another class that needs to be implemented/modified > or > should I give the name of my new Class (UdpBase64SocketHandler) to some > sort of function to be added as new plugin?
Hmmm, does chetan-transports actually work at the moment? You probably don't want to derive from UdpSocketHandler ... I'm not sure about this ... Certainly you'll need to deal with registering the transport etc. UdpSocketHandler isn't registered properly because it's not a plugin... This isn't as easy as it sounds. :( > > 2) What's the role of the tracker object? Why both _socket and the > tracker should be sending the packets? It's purely a diagnostic thing. It tracks packets to tell whether we are receiving incoming packets from an IP before we send outgoing packets to it, i.e. to detect whether we are NAT'ed. > > 3) What is the different between destination in Peer type and > destination in PluginAddress type? You probably want PeerPluginAddress. This is a specialised version of PluginAddress for stuff that uses IP:port (not all transports will). > > 4) My understanding is that byte[] data part of the packet only contains > the data part of the packet (and not the header) so the max packet size > does not need assumes that the header is also in Base64 encoding. Is > that correct? It includes the data in the packet, including any Freenet-level headers. It does not include the UDP/IP level headers. So yes, IIRC max packet size is for the byte[]? > > My implementation up to now is here: > > https://github.com/vmon/fred-staging/commit/d1830950737fa5ec0c13238d7309bef6ddaf750a > > Hopefully it'll become more realistic after I get the answer. Now that > I'm back home, I think my nights should have some intersection with your > days, I'll try to be reliably on irc at nights. If you think it is more > constructive to chat on irc, we can schedule a meeting on irc anytime between > 9:30am-4:30pm your time. If nothing in this interval works for you, I'll find > another every-day spot based on your alternative suggestion. In any > case it's good to use Google Calendar in order not to get confused with > zones and miss each other. > > Meanwhile, I'm working also on writing down the proposal based on my > previous discussion with you and toad and will share it with you guys > soon when the initial version is out. Should I include "completing > the merge and testing of chetan-transport branch" also into the proposal > or you think you'll have a chance to get over that before May 22 in case > the proposal will be accepted? Good question, hope for feedback from Chetan on this! > > Thank you very much for your help, > Vmon
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
