What arrays are there?

[Maarc]

Thanks for the information. I haven't been able to read it through exhaustively, I have to go out shortly, bloody University sucks up all my time! I'll certainly come back to it and give it some more thought though.

Just a very few quick points before I have to disappear.

1) Yes, I'm in the code as both Maarc and Abaddon.
2) We queue up the game connections and the login connections into different queues. As it stands, we use a mutex when moving from login->game, so I think the only thing stopping people from using a login thread is, well, actually compiling it and giving it a go, though it may have issues since I haven't looked at it in over 12 months.
3) I've glanced over very quickly an old copy of WolfPack (mid 2003), and the tx/rc packet structure organisation looks pretty much the same way we do it, returning a new class instantiation based on the packet ID. They might do something in the finer details, but it looks similar at a high level.
4) Yup, our socket class is somewhat chcokers in some ways, but that's because there is a semi-significant amount of data that actually pertains to the active connection, though I wholeheartedly agree that some doesn't have to be there.

Whille get back to it when I can, though, not sure how fast that'll be. But thanks for the info, still handy.

[xir]

I got a bit carried with the last post, don't worry about it. To sum up though the only thing I have a problem with is the two select() calls in the main loop. I can do it if you like. I'll need to reinstall my uo client sometime again as I have adsl now so it shouldn't take too long to install I might give the new Winsock 2 interface a go and see how that comes out too. I have been wanting to fiddle with that. I also noticed that there is already a JS wrapper for sockets and wondering if they work.

[Maarc]

Have a crack at it if you like, not a problem. Always good to have people with knowledge working on such things.

One of the reasons for sleep, at least on Windows, is because if it is not there, then it'll just flog the CPU to 100%, never voluntarily giving up its time slice to the operating system, so it becomes very choppy for anything else (say, running a client). And without it, it becomes impossible, practically, for someone to run a client / server on the same machine.

In actual fact, it's three select calls in the main loop. One for new connections, one for checking login messages, and one for checking game messages

But the main loop does a bit more than just checking some timers. Or I guess, more actively, those timers are significantly more than just checking for a world save. It also runs the AI / game loop, updating regions, weather and boat movement, as well as other things as well, for active characters and NPCs. So in reality, most of that, at least in an active world, will be time spent in those loops, not in network IO. And that's why the immediate if for the sleep call, too, no point doing fast updates in the world if no one is online to see them

[Sydius]

I love how Windows handles asynchronous sockets with the WinSock library. You set a socket to be asynchronous, and then you never have to look at it again until something happens. You get a message in your message pump as soon as something is ready to happen.

That is the difference between going to the door, opening it, checking if anybody is there, and going back compared to just doing other things until the doorbell rings.

Then you need no sleep statements, and you can use as much of the free CPU cycles for the things you need as you want. For my MUD, I sat up timers for each “idle” thing my server did, and then from there it was a purely reactionary system as opposed to constantly checking things.

Now that I am going for OS-independent code, though, what I plan to do is put each socket in its own virtual thread, and leave it blocking. Then, when an event occurs, I will have it send it to my own event queue. Do the same thing, but with a little bit of worry over mutex handling, I suppose.

[Bombzj]

[quote="xir"]Just like to say before I begin I don't mean to demean anyone's work (as it may appear so.) I've had a interest in Network I/O models recently and I've studied several examples. quote]

Your explanation on network models is really helpful. Is there any document for us to understanding uox3source?

[xir]

Your explanation on network models is really helpful. Is there any document for us to understanding uox3source?

UOX3 is like a messy bedroom, the only person who knows where everything is is the person who owns it. The only way to learn what is going on is to dig into the source and see for yourself. Normally when I analyse a project I work from the low-level interfaces and work upwards. I unfortunately haven't looked at much of the real UOX3 source (the stuff beyond the protocol.)

There are only one or two developers currently working on UOX3 so I'm not sure if such a document exists. I do remember a dated UML diagram but wheter it is useful or not or still exists I cannot say.

[giwo]

The afore-mentioned UML diagram does exist, but it's really not relevant. It was more an idea of where we were considering heading, rather than where we are at.

There is no real UOX coding documentation, as it stands. However, if you head over to www.sourceforge.net/projects/openuo you will find some basic coding standards in the documents section. Aside from that, basically the best way to learn where things are at and how they function is to look or ask. I know most of UOX and how it handles things off the top of my head after 7+yrs of working on it now, so I can generally point you in the right direction.

As for the messy bedroom, we are trying to move away from that

[Bombzj]

The afore-mentioned UML diagram does exist, but it's really not relevant. It was more an idea of where we were considering heading, rather than where we are at.

thanks for your explanation.

I want to know the framework of uox3 before digging into each part of it, so any diagram would help a lot. it seems not easy to pick the framework out from the sourcecode if I don't read most of the sourcecode through.

anyway, I've got lots of information about uox3 in this forum. uox is really an interesting work. Thank you all very much.

[giwo]

This, of course, is just a rough outline of how things stand. Note that the majority of our code lies in the subsystems. There are numerous files that you basically just have to paruse to get a feel for, but this will give you a jump start.



Server (worldmain.cpp, CServerdata.cpp)
->CWorldMain (Contains most global variables)
-->CServerData (Contains UOX.ini settings)
-->CServerProfile (Contains server profiling info).

World Objects (ObjectFactory.cpp, CBaseObject.cpp, CItem.cpp, CMultiobj.cpp, CChar.cpp)
->ObjectFactory (Creates and manages all in-game objects)
->CBaseObject (Basic in-game object others are derived from)
-->(Derived)CItem (Basic in-game item)
--->(Derived)CMultiObj (Basic house object)
---->(Derived)CBoatObj (Boat object)
-->(Derived)CChar (Basic in-game character)

JavaScript (CJSMapping.cpp, CScript.cpp, jsencapsulate.cpp, SEFunctions.cpp, UOXJSMethods.cpp, UOXJSProperties.cpp)
->CScript (Each "object" created for a JS File)
->CJSMapping (A group of maps relating a script ID to JS Files)
-->CEnvoke (A map relating a specific number to a JS Script)

Network (network.cpp, CSocket.cpp, CPacketSend.cpp CPacketRecieve.cpp)
->CNetworkStuff (Handles pretty much everything except the individual packets)
->CSocket (Object associated with each socket)
->Packet Handling

Scripts (CServerDefinitions.cpp, scriptc.cpp, ssection.cpp)
->CServerDefinitions (Each script category [items, npcs, etc])
->Script (Each specific script file)
->ScriptSection (Each specific script section)

Console (CConsole.cpp)

Subsystems
->CHandleCombat
->CDictionary (Handles multi-lingual support)
->Skills
->Movement
->Magic
->Gumps
->Guilds
->Races
->Accounts
->HTML Output (For server stats)
->Commands
->Books
->Effects
->SpawnRegions
->TownRegions
->Jail
->Help Queue
->Weather
->Message Boards
->Speech
-->CResponse (Handles NPC responses)
->Weight
->WhoList
->Map Classes
->Map Regions

Utilities
->UString
->Singleton
->CDataList