- This topic has 9 replies, 2 voices, and was last updated 11 years, 9 months ago by
.
-
Posts
-
I am trying to understand a bit more about the Client/Server use of Suneido. I try to understand where code is actually being executed. For example: I have a file on Client side that I need to locate and open. After that I want to manipulate the data. Where is the file data manipulated? On the Client side, or the Server side? Or if I give the location of the file, will it not try to locate the file on Server side, and then not find it?
Thanks,
EmileBasically, it is just access to the database (e.g. queries) that is client-server. It is similar to using other database servers like MySQL. One difference is that Suneido loads the program code from library tables in the database. Another difference is that Suneido packages the client and server into a single exe.
Database triggers run on the server. Rules may also run on the server if their result is required e.g. for a query.
If you use File to access an operating system file, that happens completely on the client. The current directory will be the client’s.
If you want multiple clients to access a file, then you need to store it in a shared directory that everyone has access to. And it is better to use a UNC path (e.g. \servercshared) (rather than mapping a drive letter) so that the path is the same for all clients. (You can put suneido.exe in the same shared location and set up client shortcuts to use it. This makes it easier to update the exe.) This shared location can be on the same computer as the server is running on, or it could be a separate file server.
Normally, it is sufficient to run your code on the clients. For special cases it is possible for a client to use ServerEval to run code on the server. But you have to be careful with this because if you run something that blocks, then you will block the entire server and all other clients. An alternative is to run an HttpServer as a client, but on the same physical machine as the server, and then use it to run anything you need executed there. Also, if you do this kind of thing, you need to worry about concurrency e.g. multiple clients running something on the server at the same time.
Note: Suneido’s use of client-server is designed for local area networks. It uses many small requests. If you try to run it across the internet, even with high bandwidth, latency will make it very slow.
Does that answer your questions?
Hi Andrew,
Thanks for your information. It makes a lot of things clear. One final thing (I think I can understand it now): if the code is running on the Client and I make a socket connection to a second Suneido Server running elsewhere, the socket connects directly between the Client and that second Server? I suppose it does. The second Suneido server is used to store data, files, etc.
The part about using it over the Internet is interesting, because I was wondering how it would perform. What is the best set-up for use over the Internet?
Thanks,
EmileYes, if you make a socket connection to a second Suneido server it would be direct from the client.
Our customers use Windows Terminal Services (RDP) to access across the internet. Another option would be to run an HttpServer and write a web app, although currently the Suneido libraries do not have much support for that (i.e. no framework like Rails).
Because Suneido’s client-server protocol allows executing arbitrary code, I would not make a Suneido server accessible from the internet. e.g. Someone could RUN System(“del *.*”) Although you could limit the risk by setting permissions on the user running the server, it is safer to run an HttpServer and use web services for access.
VPN will be just as slow as (or slower than) connecting directly since all it does is add a layer of encryption. It’s still going across the internet with the resulting latency. Unless someone had dedicated (non-internet) connections between offices (with low latency).
I have changed my file transfer in my application, from using my own implementation to using the FtpClient. It works fine, much easier to use. Bu I have a question about that: when I was searching on the internet about FTP and related issues, I noticed a concept called Zero Copy, where static content is directly moved from for example file handle to socket, and is not routed via the application. Is this also possibel in Suneido?
Suneido doesn’t haven’t anything for this (yet). I see on Windows zero-copy is done with the TransmitFile function which needs a file handle an a socket handle.
Currently, if you use Suneido’s built-in File and SocketClient classes, there is no way to get the Windows handles, although this could probably be added.
Another option would be to use the Windows api to open the file and socket so you would have the handles. There is a wrapper in stdlib for the Windows api CreateFile function, but I don’t think there is anything similar for sockets, although it probably wouldn’t be hard to add.
I wonder how much difference it would make. Network is slow, relatively. It would put less load on the cpu, but these days we usually have lots of cpu to spare.
I read somewhere that it is approx. 2-3 times faster. Of course for small files it is not an issue, in most cases you would not notice the difference. I just wondered if it would take the load of the application. I noticed for larger files that Suneido says “not responding”, until the sending has finished. Maybe if I could do it in a seperate thread, that it would solve the issue of Suneido not responding.
Thanks…To prevent delays for the user, we will often send from a separate copy of Suneido (another client) running on the server.
Windows shows “not responding” whenever you don’t run the message loop, e.g. if the program is busy sending. TransmitFile would do the same thing unless you use the overlapped / asynchronous mode.
- You must be logged in to reply to this topic.