web published game using custom networking / sockets

As I understand it a web published game can not use DLLIMPORT, which makes sense to me.

However, if I create my own sync/async socket code using System.Net, will there be any sandbox-ish issues with connectivity? For example, any limitations enforcing that I connect back only to the server which vended the page?

I guess another way to pose this is:

Will there be any differences in what I can and can't do with sockets for a web published game vs. standalone game?

On a related note, how do I use a 3rd party .net library assembly from my C# game code and have that assembly be automatically downloaded and available when web publishing? Is it even possible?

Thanks,
Ryan

 

what I did was create my own client dll

and then using c#

You just drop the dll in the assets folder then call it like you normally would

at the top

Code (csharp):

1.  
2. using MyClient;  //this is the namespace for the dll
3.  

Then below in the class:

Code (csharp):

1.  
2. ClientDll client = new ClientDLL();
3.  
4. client.Connect(); //whatever functions you create to connect to your server and send and receive messages etc.
5.  

So far with my test I haven't seen any limitations from the webplayer.

I will have a tutorial soon in the next few weeks on a basic server / client for unity.

You could look at the lidgren dll for creating your client and server to speed up dev time it works perfectly with Unity and mono.

 

Have you tried with your client to make connections to a server other than what vended the web page? I know this works in Fusion Fall.

That's great to hear that simply dropping in any old C# assembly into the assets folder is automatically downloaded and used. Very powerful.

This does make we wonder...under what security context is this referenced assembly executing? For example, can it directly access the local hard-drive, write/delete files, etc. assuming the user has appropriate permissions? Or is the plugin enforcing a particular AppDomain security context to prevent malicious code from executing?

If it runs outside the sandbox, then there's no reason to not allow DLLIMPORT. The same abuses are allowable either way from a security standpoint!

Also, will executuable assemblies work as well in the assets folder, not just dll's? As you may know, with .Net and mono, you can Reference and use public classes from either assembly type, it doesn't have to be a library assembly (ie .dll).

Ryan

 

I believe that the web player has limitations on what a dll can do due to security restrictions.
I don't know all of what these are yet.

I will test the webplayer on different machines and see what happens but it should work just fine.

When you build your app it compiles the dll into the executable from what I understand in reading the documentation.

Maybe someone from unity or with more experience can help on the security and dll's that you place in the asset folder while using the web player.

 

Can you point me to where in the docs you found this?

I'm curious to see if they are simply embedding the other assembly as a resource, or actually disassembling it and merging the IL. The later would be tricky, but quite slick. ;-) The former would be cake; done it many times myself.

Yes, it would be nice if somebody officially responds to this. I'm very curious what the security constraints are if any, and the mechanisms that are in place.

Thanks,
Ryan

 

I was looking at extensions here

http://www.unifycommunity.com/wiki/index.php?title=Extensions

So I made my a test dll and started playing around.[/url]

 

From the docs it sounds like the IL is merged. Pretty cool, avoids needing a second app domain and security context at runtime. I can imagine problems though when using 3rd party assemblies; some of them really don't disassemble well due to protection mechanisms. It would be great if somebody from Unity could confirm that this indeed is what happens (ie disassembly and IL merge) at publish time.

I do assume that the compiled game itself does run in somewhat of a locked down context when in the web player...can't wait to hear what constraints there are if any.

If anybody knows any details on that I'd really like to hear...

Thanks,
Ryan

 

basically webplayers can not access files, registry or processes on the machine. Also native plugins don't exist on webplayers (but thats self explaining I guess)

 

Not all browser plugins and web players are restricted to this, but if Unity's is that's fine.

In particular, how do you save local files for game saving? Or are game saves only supported back over the network?

Is there no piece of documentation anywhere which explicitly states which Unity features won't work when published for web player. I have been unable to find it...

Thanks,
Ryan

 

you can not save anything on the system other than PlayerPrefs
If you want to store them on a webspace, then this is up to you how you do it WWW and System.Net with the tcpsocket might be good starting points


its really only the system security related things that are disallowed, thats fileIO, registry and process access