Hi!
Locklainn wrote:
Hello all,
I have been working on a proposal for the messaging system refactoring
that takes into consideration some of the things that Tao has suggested
and would like to see.
the branch is at:
pyogp/pyogp.lib.base/brances/locklainn-message-refactoring
Thanks for working on this :-)
There is a typo in the path though, here is the full URL:
http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/branches/locklainn-message-refactoring
For examples of how this is used, go into one of the test_udp* files in
the client test folder.
Mainly, the changes include direct access to the messages so that you
directly build the messages instead of going through a builder or
reader. In essence, the builders and readers no longer store the
messages in their "state".
Also, the method by which packets are serialized and deserialized is
more in the form of ZCA and is a much better design than before.
The Message System has been renamed to UDPConnection, which suggests
that it no longer serves the purposes it did before (handles the
connection between both llsd tcp and template udp messages). It serves
only for udp connections, manages many different circuits, handles all
acking, and resending unacked.
After spending the weekend with experimenting with network code I wonder
if it shouldn't better be called UDPMultiplexer or so because the actual
connections are the circuits I think. And this class handles more than
one and needs to dispatch the packets to the individual circuits.
Here is an example of use:
msg = Message('PacketAck',
Block('Packets', ID=0x00000003, ID=0x00000002)
)
packet = IPacket(msg)
buf = self.udpconnection.send_message(packet, self.host)
Some things to consider:
Tao and I were talking about the sockets. There are two options we see:
1) each udp connection has its own socket
this means that the udp socket is connected directly to its remote
address and doesn't receive any data from anything else, or send data to
anywhere else. This could have problems if there are too many sockets
created in situations like, large draw distances and so connections with
many sims, many agents (and so sockets are multiplied) or something of
the sort
I tested this the weekend on my machine. I wrote a simple server based
on SocketServer (python stdlib) with the ThreadingMixin. It was a simple
echo server with a sleep before replying. Then I wrote a client which
instatiated 1500 connections which all then hang because of the sleep.
After instantiating 380 of them the server went down because it couldn't
create enough threads. I changed it to use eventlet. Then it stayed up
and the client broke down after about 1000 connections saying that he
has too many open files.
So 1000 sockets can be open on Linux at least. I couldn't find out how
many these are on other OSes via Google but I might run this script as
well on windows and mac later (there probably is some info somewhere).
So unless you run 100s of avatars I guess there is no real problem. And
if you run 100s of avatars you can still increase this limit in your OS.
2) there is a 1 level-higher than the circuit object that has a single
socket which dispatches to the circuit. This is how the message system
currently works. The benefit is a single socket. The disadvantage is
having the higher level object that we need to use.
After playing around with different network approaches (eventlet,
threads, twisted) I am even more unsure how to solve this ;-)
E.g. with twisted you cannot have a receive() method which waits for
something to come in from the socket. Instead this is done already by
the event loop. The event loop might then call a high level object to
dispatch the data to the right place (and keep track of acks and such).
So I am not sure if our idea of a lower level networking layer actually
works here and I am also not sure if it works for the TCP part (if you
e.g. also want to do it with twisted).
So I couldn't come very close to a solution and I also didn't think
about the event queue for now. But in general I think it should be
possible for the application to decide which networking approach to use.
This maybe means that it needs to do the low level networking stuff
itself maybe with the help of some helper classes.
But I at least need more thinking and maybe more experimentation. The
problem here really is that for this to solve properly we need to know
more about how the lib might be used. So I would actually expect this to
change in the future depending on what we learn.
What we definitely need of course is the circuits which keep track of
acks, know which packet id is next and so on. So the question here is
mostly what to do with the higher level object.
We also need to think about where threads might make problems, like
where things might be not threadsafe. Here I am also not sure how this
could be implemented because at some point you have the sending and
receiving of messages e.g. in some Region class and don't do it
directly. How can we put hooks in so that things can be locked in the
right spot? Or maybe we can work around this and make sure no locking is
needed? The only spot where I think it's needed right now might be the
incrementation of the packet id. But += should be atomic so no locking
should be needed. There is still the possibility if 2 threads do this at
the same time, that id 15 is sent before 14 but this is possible with
UDP anyway and shouldn't break things.
But I will try to post a more detailed report on my experiments later.
You can also check out my sandbox networking stuff I checked in:
http://svn.secondlife.com/svn/linden/projects/2008/pyogp/sandbox/trunk/sandbox/mrtopf/networktest/
But I am not sure it makes sense without further explanations.
The README in there was written before the tests btw and it's most
likely not fitting the results ;-)
You can find the twisted version of the client in 2/ though.
cheers,
Christian
--
Christian Scholz Homepage: http://comlounge.net
COM.lounge blog: http://mrtopf.de/blog
Luetticher Strasse 10 Skype: HerrTopf
52064 Aachen Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0 E-Mail [EMAIL PROTECTED]
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
