[Released] TNet: Tasharen Networking Framework

Asset Store Link
http://u3d.as/content/tasharen-entertainment/tnet-tasharen-networking/3QM

What is TNet?
In short, TNet is a networking framework using TCP (and optionally -- UDP). It has a simple and straightforward design and thoroughly-commented code, making it easy to work with. As some individuals noted, "TNet for Networking is like NGUI for UI", although personally I think that's setting the bar a bit high there for a new product.

Just like with NGUI before it, I plan on supporting TNet as long as people use it, and I will add more features to it as the time goes on, so if you don't see a feature you really want -- request it! If it makes sense, I will add it. Just keep in mind, TNet's goal is to be the easiest to grasp networking solution. If you need out-of-the-box features like encryption or anti-hacking, TNet might not be what you're looking for.

If, on the other hand, you just want to add multiplayer to your game with simple server discovery, hop-in hop-out gameplay and persistence, you will find TNet very useful indeed.

So what does it offer?

• It's Open: written in C#, comes as full source code for you to modify as you see fit.
• It's Readable: The code was written for others: it's clean and thoroughly commented.
• It's Flexible: Server can be stand-alone, or started on another thread right within Unity.
• It's Adaptable: "Host" disconnects? Choose another. The game doesn't end. Everyone disconnects? Save the state (if you want).
• It's Persistent: Not only can remote function calls be saved for future players, but you can save the entire server's current state and then restart it. When you start it back up, it will be as if you've never shut it down (Auto-save anyone?)
• It's Powerful: Written to take advantage of high efficiency sockets (IO completion ports).
• It's Spacious: Each channel on the server is a separate area with its own rules (and save file), letting you host as many simultaneous games as your bandwidth can handle.
• It's Private: Playing by yourself? Put a password on the channel, or just flat out lock it. Others will still be able to PM you, of course.
• It's Consistent: You don't need to put "if" statements everywhere. Same code that works for multi-player will work in single-player. The callback order is always the same. For example, players always get "left channel" notification before a "disconnect".
• It's Efficient: You can optimize your frequent remote function calls by specifying a byte ID instead of a function name. Less data will be sent.
• It's Straightforward: Remote function call syntax and number of parameters are up to you. Arrays? Sure. Binary data? No problem. A hundred parameters? Uh. Well, sure, if you want.
• It's Elegant: You can even broadcast messages to players on the same LAN or wireless network without requiring them to connect to the server. Perfect for announcing local servers, for example.
• It's Useful: You can save files directly to the server, and load them later, letting players save their avatar thumbnail, inventory, or even an entire game map for others to load.

Platforms
TNet supports all platforms except Unity Android Basic and Unity iOS Basic. Flash supports TCP, but not UDP.

Documentation
http://www.tasharen.com/?page_id=4518

Examples (older builds)

• Windows
• Mac OS X
• Android

 

Awesome. This is on my to buy list for after the festive period.

 

Not sure if i'm first, but purchased

 

(bookmarked)

 

I'm a bit confused, i wanted to start with the example scenes but there was no connection info in all except menu, from what i understand you go from the menu scene, connect, and then go to the other scenes but when i'm in the menu scene, i can create a server (and view it from other instances) but then clicking on any of the "exemple 1. . .3" or "exemple chat" does nothing, i expect it's supposed to load those scenes but for me it does nothing, regardless of if i'm trying in editor or on standalone.

 

Aaaaaand nevermind, posted to quickly, simply didn't add the other scenes to the build (didn't think it would matter in editor so had discarded that too early).
Free bump i guess

 

Any Special discount for combo of NGUI and Tnet (we are planning to buy NGUI Tnet).

I dont have much knowledge about Networking, but futurewise can we compare it with smartfoxserver or photon?

Can we connect databse through Tnet?

Any plan for relase step by step tutorials for Tnet like NGUI?

Is it also support webplayer ? (can we play its online, like sfs or photon)

 

Yes it supports the web player, but you can't host a server from the web player. You can connect and play just fine though -- http://www.tasharen.com/tnet/ <-- web player build.

NGUI is 50% off right now until the end of the year, and that's a pretty hefty discount.

TNet is for communication between clients through a server, and doesn't know anything about databases, so nope. The code is open for modification, however -- so if you already have something that needs a database back end for which simply keeping saved data on the server isn't desirable, you can just add it in.

Edit: P.S. Step by step -- http://www.tasharen.com/?page_id=4537

 

I see you don't support mobile because of .net socket issues. Any chance you can work around that in the future and support them?

 

Mobiles are supported fine, but you need pro for them. Its a limitation in unity, no work around it.

 

Any future plan for adding Database support in your framework ?

I opened a link of webplayer provided by you. I already have tnet desktop demo. I opened that desktop exe and started as local server. From that webplayer link i just clicked on connect to 127.0.0.1 and its showing "connecting...." message since last ten minutes. So how to connect it?

 

-

 

The web player and desktop are different versions. I built the web version at a later date. You just reminded me to fix that...

 

Actually as someone who purchased, and who isn't a first post, but who hasn't had the time to test it, i'd love to see answers to a few points by this troll for clarification as some seem unbiased (he may be right or wrong, but it seems he did his research)
Points i don't care about:
- Comparison with built in
- Usage of binaryformater
- Comments on usage
Points on which i'd like to see you reply
- Performance (and a quick talk about expected performance) of the library over internet, both TCP and UDP
- Confirmation about receiving the same packet multiple times
- Having to use IDs for methods, i didn't go to that point so i'm clueless, and also his statement about being limited to 256 such methods
Thanks!

 

-

 

wow, ive been browsing the forums for some time now, but just had to sign up for this.

First, a bit of a background - i have been looking for a solid networking solution for a few weeks for a project. i started with unity's networking like most people i guess, and ran into so many problems with it i dont know to even where to start. anyone can do a search on the networking forum to see the many issues with it i think so no point in going over them i thnk.

Next i tried photon, and its actually pretty good, but seems to be a little unstable? may have been just my luck with their cloud, i dont know. i had many random disconnects. the code was a little difficult to work with too, although the auto-conversion from unity networking to photon was great.

I looked into lindgren and ulink a bit, but both seem to use only udp which doesnt work on ios basic and flash. we dont need reliable udp at all, tcp is fine.

tnet seems to be the only one that offers all that, and is cheap too. code is great, very easy to follow, and examples are simple and easy to understand - all thats needed to learn how to do things quickly. there is no auto conversion script like in photon, but it only took me about an hour to port the prototype from photon to tnet to try it out, and amazingly all the issues seemingly went away. i have only been playing with it for a few hours but i have to admit i am impressed. easiest and most stable networking package i have tried yet. the code is openly available too, so if something goes wrong i acn fix it if needed.

and now for this thr fellow: i dont know what your deal is with the aronmook but i too think that you are trolling here. maybe you are an author of a competing package who doesnt like competition, but i say you put your money where your mouth is:

- tnet is not using reliable udp that you seem to think it should - where did you even see it mentioned? reliable udp and basic udp are two different things. udp packets can arrive in the wrong order, but with often updates this does not matter at all. its also very easy to add your own number to the packet and discard out of order stuff if you care - just an extra parameter to pass to your rfc. and if you dont, you say its a major problem? have you evern written a single networkd app?
- tnet does not mention NAT punchthrough anywhere - again where did you even see this that you are complaining about?
- you complain about adding items you need to create to a manager class? lolwhat - clearly you have never tried other packages as they all need to do this
- binarywriter is in efficient? not any more ineficient than any other mono class. do your research.
- the library gives you nothing over unity networking? are you high? have you even tried using it? lol apparently not
- you complain about specifying a byte identifier which is optional and limited to 256? if you plan on having more than 256 remote function calls on a single network view then you are a fool. and you claim its the only way to get performance? again lol what?
- this package was released on christmas eve yet you are already here the next morning complaining with a "comprehensive" review? i call bs.

now its important to note that i was only playing with tnet for a few hours now, and i have never had a reason to post anything good or bad, but the thrs post was just too full of bs to pass up

 

-

 

-

 

I'll have to side with thr there, while his review was "harsh", it doesn't sound like a troll to me at all, he definately purchased it, a troll wouldn't purchase to troll, and he raised points that may be issues on his side (things that he expected and weren't marketed etc), but i don't think he's being handled properly there, he didn't insult anyone or anything like that and he did raise a few questions that i said i'd like (as a "certified non troll") answered that have been eclipsed by the "troll vs nontroll" superbattle that is starting.

- a happy tasharen water ngui customer.

 

Fred is right. 255 is per TNObject, not per app.

 

Is this targeted at me or thr? this is getting confusing, i don't know you outside of the 15mins you've spent helping me on skype with tasharen water long ago, and i don't have anything (yet) on the asset store nor am i planning anything that could compete with TNet, and as i said i'm interested a answers to a few (i mentioned them) of this questions.

 

-

 

@thr - You have of course the right to ask for a refund if you personally are disapointed with the product offered. However, may I ask that you take this into a private discussion with Aaron from here on. In all fairness, your opinion is just one opinion and it may not even be just. Therefore it may affect peoples decission as to wether to buy it or not. Looking at Aarons past products (which have been selling great) I noticed that he has always been helpful to customers. So please take this into email or PM conversation from here on. This is in the interest of the users who are interested in this product. I am sure many people have questions and I am pretty positive that Aaron will do his best to answer them.

 

But no one's been answering me all along, i'm one of the users, and some of the questions thr raised "are" of interest to me.

 

@ronan: To address your questions:

Comparing TNet to built-in networking.
Built-in networking has a lot of limitations. For example:

• When some client starts a game (and is thus the authoritative host), and then leaves the game, the game ends. With TNet a new host is chosen from the connected players and the game continues.
• When some client leaves, all the RPCs made by that client are erased. You can't keep them. With TNet they are kept if you wanted them to be kept.
• When some client disconnects, all objects that client created are removed, whether you want that or not. In TNet they are kept.
• In Unity's built-in you can only pass int, float, string, player, view ID, vector3, quaternion and byte[] as RPC parameters. You can't add your own. In TNet you can pass bool, byte, int, float, string, vector2, vector3, vector4, quaternion, color32, color, datetime, and arrays of most of them. Plus you can add your own (TNTools.cs).
• You can't buffer (save) RPCs on dynamically instantiated objects using Unity's networking. You can with TNet.
• You can't save RPCs in a channel when the last player leaves using Unity's networking. You can with TNet. So if you move objects around then return to your room later, they will be where you left them.
• 1000 buffered remote function calls to the same function means 1000 function calls stored on the server and sent to new clients. 1000 saved identical function calls in TNet = only the last one is kept (Think: saving the latest player position on the server with frequent updates for 15 minutes -- ouch!)
• Destroy calls using Unity's networking do not cancel out create calls. They do in TNet (so less data to send to new clients).
• You can't modify Unity's networking to suit your needs as it's all internal. You can freely modify TNet as it's all open.
• I can go on like this, but honestly... do I really need to?

Using BinaryWriter
Fred is right, it's really not any different than anything else in Mono. "Super inefficient" it is not. Besides, there is no alternative to it, and TNet actually keeps buffers around and re-uses them, so there is no needless GC.

Performance over the internet
Exact same as any other package or built-in solution. You send the same data across the network. If you get 300 ms ping using Unity's networking, you will get 300 ms ping using TNet. UDP vs TCP is all primarily BS for the most part unless you are playing with very high ping and heavy packetloss, which makes UDP better. Unless you are making a AAA FPS game, you can do everything over TCP. Although using UDP is still an option if you want it. It's not reliable UDP though -- meaning packets can get lost or arrive in the wrong order (which happens rarely), but for things you send 10-20 times per second one out-of-order packet is hardly anything to get your panties in a bunch over. There will simply be another packet arriving 50 milliseconds later.

Furthermore, you can (and should) separate physics from rendering, making your renderer "lag" behind your actual object slightly, easily smoothing over any irregularities. If performance is really critical and you really are making a AAA game, there are many approaches on the internet that talk about how to compensate for ping delay, packetloss, etc. It's really all up to how deeply into networking you want to get. Despite what fholm wants you to believe, there is no "magic bullet" and all developers either have to just stick with it, or get creative (like in my example with making the renderer trail behind slightly, or extrapolating where the player should be). Either way, this is something that should be done only for very specific types of packets (position), and is never something that should be handled by the network layer.

Receiving packets more than once

With UDP you don't receive packets more than once. You either receive them, or you don't (but very rarely in a different order).

Having IDs for methods
This is an optional feature. You don't need to do it. It just makes sense to do it for frequently called methods. You can have up to 255 unique IDs per TNObject (so on a single game object). You can have as many TNObjects as you like, however -- and each one can have a different set of IDs on their functions. So realistically speaking, why would you ever need more than 255 unique RFCs on a single object?

 

Thanks (and you even answered those i didn't need hehe).
I had a feeling most of the issues were unfounded but i'm happy you clarified them, the double packet in particular worried me.
256 on a TNObject = 256 methods per object i see (if i want to go the id version), i thought it was per session or something similar, per object it sounds well, huge.
Side question i've seen there's a zip with a server, is this for hosting outside of unity or does this require unity? For exemple could i hold 1 connection between multiple unity client and another connection to something unrelated to unity? (I'd like to be able to use something without instancing unity serverside for non realtime game things, like hosting savegames etc).

 

-

 

Sure, fholm. And sometimes there are fluctuations in power that may cause disturbances. Let's talk about that too, like that's also a major global problem.

Nope you don't need Unity to host a server. It's completely stand-alone. The executable that I included is only 35 kb as I recall. You can run it anywhere. If you check Tasharen Forums, there is an explanation another user posted on how to run it on the Mac, for example (and with my reply explaining how to get it compiled on win / mac / linux).

 

@thr,

If you know so much about networking why do you need this package in the first place?

Roy

 

Got no clue if it's the same person or not, but if someone decompiled your unreleased stuff you should definately do something about that, that sounds pretty bad to me!

 

This is hilarious, been laughing for like a good hour, guys ... please keep going. Oh and on the "decompiling unreleased stuff", perfectly fine, if you put up a webplayer or send out compiled unity games be prepared for things to get de-compiled and looked at.

 

You definately shouldn't be "prepared for things to get de-compiled", you know it happens but, stating you did it publicly is well, downright "censored".
If it was me, you'd be receiving letters from my lawyer.

 

@fholm, your private messages indicating my IQ must be pretty low are not solicited and serve no purpose, let's keep civil and in the thread, a dicussion here is of interest, a PM between both of us, who obviously aren't likely to ever collaborate, is not.

 

Sigh...can we just stop making unfounded accusations?

 

Any quarrels anyone may have, take it to PM's! Feel free to post constructive criticism and any questions, if you are unhappy with the product then contact ArenMook directly.

[edit] And lets keep this thread on topic.

 

THIS!

Or .... Send you a PM

 

I was really excited to see this package available in asset store. I currently use SmartFox, but I want a peer to peer solution. Does your system support peer to peer?

I don't want to get involved with the embarrassing thread war going on above. However, comments "noticeable jitter and lag spikes" are a big concern. Could you please advise what overhead TNet adds to processing. [EDIT} just to be clear, I am not asking for an explanation on packet lag between clients and differences between TCP UDP. I just want to know what overhead TNET will add to an update/fixedupdate cycle, to ensure frame rate doesn't get impacted.

 

Don't pay attention to fholm aka thr. I addressed all the "concerns" in this reply: http://forum.unity3d.com/threads/16...ng-Framework?p=1119245&viewfull=1#post1119245.

And yes, you can do peer-to-peer by simply hosting a local server within Unity (hit the host button on the provided example).

 

I agree he is nitpicking. But unless I didn't read correctly there is no proof of him trying to make sure his own networking wrapper doesn't lose sales.

I would suspect the admins would of already checked for multi-accounts(although these are easy to trick, proxies, restart router(Except subnet), etc etc) for anyone that knows as much in networking as he does.

Anyway, on topic;
I really like this and I'll be considering it once it's been around for a few more months. Looks good so far though.

 

I want to add that selling an open source project in the asset store is pathetic.
Lidgren is freely available and can be integrated in Unity in less than 15 minutes.
There's simply no reason to pay 20$ for this. And to be frank, i think it's quite immoral too.

Oh and - nice library ArenMook!

Small advice from me:
Whenever you release an alpha/beta to the public, make sure you include a License.txt
that forbids decompilation. So next time someone thinks he can do whatever he wants with your
property will have to face consequences.

 

You don't need to disallow decompilation, simply not explicitely allow it. It's up to arenmook to do something or not but, were i in his shoe and as i mentioned before, i'd be talking with my lawyer.

 

One question about the server ,is it a headless unity or just a socket server? Can I run physics simulation on it?

 

No physics. It's a socket based server, and Unity isn't involved. So in short: there are only physics happening if there is a client connected. If there is no client, the state of everything is saved until a client joins.

 

Yesterday we purchased NGUI and Tnet. We have NGUI video tutorials. Some of my collegues going to use your Tnet framework. I think if you will make some basic video tutorials then it shoud be very helpfull to them and also for those people who are going to purchase Tnet.

 

Do you mean combining TNet's usage with NGUI, or getting more in-depth than the video on TNet on the front page?

 

Video tutorials short series covering basics, synchronize a player movement, damage to player etc would be very helpfull

 

I agree ... video tutorials would be really helpful.

 

Sure thing.

Next version actually adds a pair of new scripts -- TNAutoJoin that will automatically join a channel on a remote server for you (no need to click anything), and another to sync properties of your choice, letting you simply say "I want this property to be sync'd across the network". TNet will do the rest.


And yes, it will only send the updates if the values actually change.

 

Any ETA on next version? If it's soonish i'll probably wait for that release before toying around with TNet.

 

Should be this weekend.