Hello all. New to this forum and ChatScript in general.  Tried finding answers in the ChatScript documentation but came up short.

Our existing Unity application employs a C# ChatSocket plugin using .NET Networking classes to connect to our ChatScript server.  Previously, our client application consisted of Unity web player builds that would connect directly with ChatScript.

However, since Chrome is phasing out NPAPI support (essentially rendering the Unity web player useless) we are now forced to create a WebGL version of our Unity app. Problem is, we cannot use our old ChatSocket plugin since it relies on the .NET Networking classes. So we need a new method for connecting with ChatScript that the WebGL builder will support.

Unity offers WebSockets as a possible solution for networking issues…so my question is: Is it possible to communicate with ChatScript using WebSockets?

Sorry if this is an obvious question…I’m not a networking expert by any means.

The answer is yes, but the CS server does not support them natively.  Basically there would have to be some intermediary provided.  There is a HTTP server mode that CS can build on linux - you may be able to add support using that.  Another would be a proxy of some sort - there are multitudes of cgi examples you could leverage. 

Websockets is a separatate protocol that ‘floats’ on top of http - there is actually a bidirectional persistant channel open for full duplex io.  It would be pretty easy to implement some wrapper using a lightweight http server that already supports websockets and actually embed CS as a shared library so there isn’t the extra net connection/hop a proxy would create.

Is a web version of your app a requirement?  Because I’ve embedded CS directly in unity desktop apps.

Todd Kuebler - Jun 19, 2015:

The answer is yes, but the CS server does not support them natively.  Basically there would have to be some intermediary provided.  There is a HTTP server mode that CS can build on linux - you may be able to add support using that.  Another would be a proxy of some sort - there are multitudes of cgi examples you could leverage. 

Websockets is a separatate protocol that ‘floats’ on top of http - there is actually a bidirectional persistant channel open for full duplex io.  It would be pretty easy to implement some wrapper using a lightweight http server that already supports websockets and actually embed CS as a shared library so there isn’t the extra net connection/hop a proxy would create.

Is a web version of your app a requirement?  Because I’ve embedded CS directly in unity desktop apps.

The web version is a requirement. The bots (Virtual Patients) are accessed via links in eLearning Modules and we don’t have the ability to embed any sort of Unity executable into the modules.

We could run the CS server in Linux if necessary, but I thought the Windows and Linux CS servers handled external communication the same.

Thanks,

Doug

The linux version of the chatscript build has an optional high performance http server instead of tcp - I think Bruce added that a long time back for a client who needed a very high lvl of transactions/sec.  It may be available for windows, but I don’t think so ( had to suppress it’s build for mac os x because of it’s use of a linux only os function call ).

Probably the simplest thing for your needs ( I’m making some assumptions here based on what I already know about your project, but I think they are accurate ) is to google ‘websocket tcp proxy’  and look at those proxy solutions.  Any of the top hits look good to me.  If you are restricted to windows I’m sure there is one there you can use as well but I didn’t see one at first glance.

Basically it goes like: 

[browser]<—-websockets—->[websockets/tcp proxy]<—-tcp—->[chatscript tcp server]

On our end, we decided to use a php script based on what is in the CS web interface folder: Unity parse and store the response, send it as a POST request to the php script, who in turns relay it to the CS server (and open the socket+wait for the answer). The response then does the same in reverse, back to Unity.

Using a dedicated websocket proxy seems like a more elegant solution, but in our case this simple php relay was a lot faster to implement and made our project webgl ready.

Todd Kuebler - Jun 20, 2015:

The linux version of the chatscript build has an optional high performance http server instead of tcp - I think Bruce added that a long time back for a client who needed a very high lvl of transactions/sec.  It may be available for windows, but I don’t think so ( had to suppress it’s build for mac os x because of it’s use of a linux only os function call ).

Probably the simplest thing for your needs ( I’m making some assumptions here based on what I already know about your project, but I think they are accurate ) is to google ‘websocket tcp proxy’  and look at those proxy solutions.  Any of the top hits look good to me.  If you are restricted to windows I’m sure there is one there you can use as well but I didn’t see one at first glance.

Basically it goes like: 

[browser]<—-websockets—->[websockets/tcp proxy]<—-tcp—->[chatscript tcp server]

Thanks. I’m looking into the websocket tcp proxies right now.  I’ll update this thread when I discover something concrete.

Todd Kuebler - Jun 20, 2015:

The linux version of the chatscript build has an optional high performance http server instead of tcp - I think Bruce added that a long time back for a client who needed a very high lvl of transactions/sec.  It may be available for windows, but I don’t think so ( had to suppress it’s build for mac os x because of it’s use of a linux only os function call ).

Probably the simplest thing for your needs ( I’m making some assumptions here based on what I already know about your project, but I think they are accurate ) is to google ‘websocket tcp proxy’  and look at those proxy solutions.  Any of the top hits look good to me.  If you are restricted to windows I’m sure there is one there you can use as well but I didn’t see one at first glance.

Basically it goes like: 

[browser]<—-websockets—->[websockets/tcp proxy]<—-tcp—->[chatscript tcp server]

It occurs to me that the word ‘proxy’ above should more accurately be ‘protocol bridge or ‘protocol converter’’.  However the primary player in this space ‘websockify’ calls itself a proxy ( it was formerly called wsproxy ) as do many of the other solutions.  But for those highly precise and finicky people out there it’s really a protocol bridge or protocol converter we are talking about here.

***UPDATE***

Thanks to everyone for the advice on this issue.  I apologize for the late reply but things hectic.

We decided to go the proxy/ protocol bridge route, specifically implementing websockify (https://github.com/kanaka/websockify) on our server, along with a modification of the websocket wrapper extension package that Unity3D provides on it’s asset store. It was a little tricky, but once we got websockify installed it went pretty smoothly.

So we’re now producing full-functioning versions of our virtual patient in WebGL builds that communicate with ChatScript.

Thanks again!