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. > 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. 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 EWOULDBLOCK 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 established, it would 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! 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. > > > > 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! > > > 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 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! 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 > > > -- > Stéphane > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
