2009/4/2 Mark Lagendijk <mar...@marksspeelhoekje.nl> > Youness Alaoui wrote: > > > > 2009/4/1 Stéphane Bisinger <stephane.bisin...@gmail.com> > >> Hi, > > Hello Mark! Welcome to the mailing list! :) > > >> >> >> 2009/4/1 Mark Lagendijk <mar...@marksspeelhoekje.nl>: >> > Since I hated the adds and looks of msn messenger, I switched to aMSN a >> few >> > years ago. I have been an enthusiastic user since. Around a half year >> ago I >> > saw the blogpost of one of the developers about aMSN 2. I thought it >> would >> > be fun to start contributing, but since there was only a 'getting >> started' >> > guide for Linux I lost interest and forgot all about it. >> >> It is nice to know that some people prefer aMSN to the official client! >> >> > A month ago I >> > searched for a Windows guide again, but it still wasn't there. I then >> > decided to make this guide myself, afterall it couldn't be any harder >> than >> > getting the amsn2 code, installing python and maybe a few other things. >> > These 'few other things' turned out to be quite a few (see my post on >> the >> > forums: http://www.amsn-project.net/forums/viewtopic.php?p=37552#37552), so >> > it took me around a day to get it working. >> >> Well I think it is an average time when you have to figure out "few >> other things" to get started, hopefully your experience will shorten >> this time for other users! >> >> > It was then that I found out that I couldn't log in. I spoke with a few >> > developpers on the irc channel, and said that I would fix the bug >> myself. >> > >> > There turned out to be 2 bugs: >> > The first bug is that the socket object has the status 'OPEN', but in >> fact >> > isn't open at all. This means there is a bug in the sock class (or one >> of >> > its super classes) of the 'gnet' module of pymsn. I spend some time >> trying >> > to analyse this bug. I found out the following: >> > >> > The actual opening of the socket returns the 'EWOULDBLOCK' error code >> (line >> > 99 of 'iochannel.py': err = self._transport.connect_ex((host, port) >> ). >> > Might this be the problem? In the code this error is handled the same as >> no >> > error: the status is set to 'OPEN'. >> > The bug doesn't occur when opening 'test.py' from pymsn. Has this >> anything >> > to do with some sort of threading? (I am new to python and don't know if >> it >> > has threading, or how it uses it). I do not know why it works in test.py >> and >> > not in aMSN2, but I do know that the socket object it self is >> responsible >> > for making sure that it is really open when it says it is. >> > When I put a 'sleep' of 1 second in the 'post open' function the bug >> didn't >> > occur anymore. >> >> First of all I must say that I know close to nothing about the >> internals of PyMSN so I'll give you some general advice on how to find >> an answer on your own: first of all I'd try to find out what an >> EWOULDBLOCK error code means. Then you could dive into the amsn2 code >> to see how it handles connecting and how it is different from test.py. >> This has 2 advantages: first you familiarize with the code, and second >> you could find a way to reproduce this bug in a simple test (for >> instance by modifying test.py). If you achieve that, you can have a >> better understanding of the issue and could figure out if it's a PyMSN >> bug or an amsn2 one. >> > Good advice, but I did that allready. The problem was I got stuck and > didn't know if I was fixing the symptoms or the problem itself. > > As for threading, Python has its own threading implementation, but it >> is an internal rewrite of threads and so it basically doesn't work >> with C extensions. We are using Gobject's implementation for >> threading, you may want to check that out to get a better >> understanding. > > I will check it out when I have the time. > > Well, EWOULDBLOCK is easy, it's because the socket is in 'non-blocking' > mode, which means when you do a 'connect' or 'send' or 'recv' it will not > block until the operation is completed.. the error EWstablished, it > woulOULDBLOCK means exactly what it says, it means that the operation WOULD > BLOCK if the socket was not non-blocking.. in other words, if you do a > 'connect', the error EWOULDBLOCK means "there was no error, but the > connection has not yet been ed block if you wanted it to finish connecting, > so just wait and ask me later if i finished connecting" which basically > translates to "the socket is not yet OPEN, I will notify you when it > actually does become OPEN". So the state of the socket should go into a > 'CONNECTING' state before going into OPEN state and listen to the socket > events to figure out when it becomes OPEN (usually a 'writable' event means > that the connection has been completed). The sleep 1 is what makes the > difference, you force it to wait until the TCP connection finishes being set > up! > > That's what I thought. I wasn't sure though and it is frustrating to try to > fix something when you have > > About threading I don't know and I don't think so.. look at > amsn2/protocol/protocol.tcl and compare it with test.py, but I don't think > there is much difference.. I think the only difference is maybe that test.py > is slower for some reason by doing some processing, so by the time it > finishes, the socket was already done connecting. > > O > I think part of your message was lost :) Yes, it's frustrating but that's also why we code! because it's also fun and we love challenges and it's very rewarding once you figure it out! :) With experience you end up understanding all that stuff! A few years ago I would have answered you ":o"
> > >> >> > The second bug occurs in both aMSN 2 and test.py. >> > >> > Only one package (2048 bytes) from the soapresponse is read. After this >> the >> > socket closes. Should the socket stay open? Or should it close, but >> first >> > pass the data it received? >> > >> > When I also use a workaround for this (changing the 2048 bytes to 8000, >> so >> > the first package contains the whole response) I am able to log in and >> chat. >> > >> > Is there anyone (who knows the ins and outs of sockets), who can fix >> these >> > bugs, or point me in the right direction? >> >> Sockets on windows are quite different from sockets on *nix so there >> could be a difference in behaviour in Python too. You should check >> with the documentation about the sockets and see if you can find >> something about this. If on *nix systems logging in works it means >> that we are receiving the whole data, hence the logic should be there. >> You'd have to find where and why it stops on windows (it would also >> help to find out if it's something that happens on every windows box >> or it's just on yours). > > This also seems like a simple issue! > Actually the server sends you the response then closes the socket.. I'm > guessing that on linux you get a 'readable' followed by a 'closed' event.. > but on windows you get the 'closed' event as soon as it happens.. so what > pymsn does is that when it gets the 'closed' event, it closes everything and > thinks it's done.. the solution would be to do something like : > if event = 'closed': > if socket.data_is_available(): > buffer += socket.read_all_remaining_data() > process_close() > (this is of course pseudo code) > When your socket is closed, just make pymsn read whatever the system stored > in its buffer before closing the socket locally, so you don't miss anything! > This should fix it! > > Actually I did do exactly this at some time, but then I thought: "if the > socket doesn't close on Linux, it shouldn't close on Windows" and I > concluded that I was fixing a symtom instead of the problem itself. So I > will only have to do that fix again. > Hehe, yeah, actually the socket is closed on both windows and linux, but linux just waits for you to finish the last chunk of data before telling you it was closed! :) > > >> >> Workarounds like yours are fine, but a full understanding of the issue >> would be advisable: it leads to better solutions. > > Actually, I disagree.. workarounds are fine for TESTING, but I would REALLY > like aMSN2 to be as clean as possible, no hacks anywhere! And I know that > Ali Sabil (original pymsn author) wrote the whole pymsn library with exactly > this idea in mind, he did a lot of engineering to make sure there would be > no hacks anywhere in the code, so trying to fix the thing correctly is the > best solution... I think my tips above should help you enough in fixing > this! > > I agree, I never meant the workarounds as fixes, just as a means to find > the problem. > > > >> >> >> I hope I could help you a little on your way to find your own answers >> ;) Hopefully there is someone who knows better than me and will help >> you further. > > Thanks Stephane, I hope both our answers were helpful for him! > > Thank you from me too. You gave good advice on how to get at the bottom of > those bugs. I did allready do what you suggested, though (except the part > about threading), but you couldn't know that since I didn't say so ;). > > Anyways, Mark, I don't know if I already took the time to thank you for > what you're doing! I hope you best of luck and thanks for contributing! :) > KaKaRoTo > > Thanks! And thanks for your tips. Now I know where the problems ly and how > I can fix them. > And thanks to you especially for taking the time to look into this problem and fix it! :) > > Mark > > > >> >> >> -- >> Stéphane >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel >> > > ------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------ > > _______________________________________________ > Amsn-devel mailing > listamsn-de...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/amsn-deve > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel > >
------------------------------------------------------------------------------
_______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
