I would like to implement a server app in Swift, with two listening (server) sockets with different functionality sets exposed. The app itself is a kind of smart proxy - transformer of data between the two sockets, with a little persistence thrown in. I have tried to prototype the app in Vapor, but it seems that multiple server sockets in a single app is somewhat an unexpected use case. Doc suggests that Application container is a singleton, it has a single runningServer property, and it takes a single Services struct where Router is registered - where i would need practically two separate routers. Now i'm having some ideas, involving either multiple Vapor Applications inside "my application", or some usage of subContainers, though i don't know how exactly the service registry sharing works. Or maybe something around Providers which i don't fully understand either. But in any case, it all feels like that i'm fighting against a clean design decision of "1 app = 1 server". Anyone prove me wrong?
Related
I need to make TCP based decentralised chat app for local network. By decentralised I mean there is no central server. Each entity on a network should have server/client architecture. When app starts it should check which user is online ( already running the app ). My question is how can i check that? Can i do it by trying to connect via connect() function from socket library? I'm new to programming, especially socket programing, so if it's a dumb question sorry in advance.
You should definitely study how other decentralized applications do this. There are lots of techniques.
Each instance of the application should, as part of its server functionality, track the addresses of other instances of the application. Each instance should, as part of its client functionality, keep track of a few instances it can connect to. Prefer instances that have been around for a long time.
The software should include a list of servers that have been running for a long time and are expected to typically be available. You may wish to include a fallback method such DNS, maintained by anyone willing to keep a list of well-known servers offering access through a well-known port. The fallback method can also be IRC or HTTP.
If you want to stay decentralized, you might want to try multicasting or broadcasting a request packet to all hosts on the network to discover other instances of your chat application.
Something similar has been implemented in Pidgin, named Bonjour. It works quite nicely and provides chatting capabilities on a local network. More specifically, it is defined as a Serverless Messaging part of XMPP.
If you are looking for code examples, have a look at one of my projects where I use multicast to discover hosts on the local network that provide a specific service: Headers and implementation.
I'm developing a socket server game using java. I want to test if server works properly (how it handles received messages, process and response in right way...) without using game client(heavy and not completed). Messages from client maybe raw binary and encrypted.
Is there a framework, or testing tool for this case?
There are several steps that I take when testing client server systems and mostly I tend to use "normal" unit testing frameworks for this kind of thing, though it only works if you've already designed your code to be unit testable. I also often write a specific stress test client for the server; this can create many thousands of concurrent connections and perform operations on the server and check that it gets the expected results.
For initial server testing you want to have a set of unit tests in place for the key server components; message parsing, etc, and you want to have isolated these components from the code that actually deals with the network (so that you can test it all in a unit test). Push data into the server's message parser and make sure that it parses correctly, and calls the right things, etc.
You can then use your normal unit testing framework to create an instance of your server object (with suitable mocks) which listens on the network and then create a simple client which you instantiate within the unit test and which tests aspects of the server. Often you'll find that there are only a small number of things you actually MUST test like this. Normally connection establishment and termination issues which you want to test with the network as well as independently of it (after all, you can call the connection establishment and disconnection code on your server class from a normal unit test anyway).
Finally you need a custom client which understands your protocol and can put pressure on the server with 1000s of clients - this is the best way to drive out performance and threading issues.
I tend to work on all of these things from the very start; see this blog post for more details.
If you want to do it by hand, I would suggest telnet or, if you're using Linux, you can use netcat command nc.
If you want something that can be automated, e.g. a unit test, and you're familiar with Python, I would recommend using Twisted: Twisted Examples
Hope this helps
Apologies if something similar has been asked in the future but my search didn't return, what I would consider, directly related.
I am trying to implement a service with its backend in AWS EC2/S3 and front-end in iPhone and the service is more or less like a todo-list. This is not a novel idea but will help me in a class I teach about IT infrastructure.
Unfortunately I have access to only my own iPhone and I cannot demonstrate scalability over AWS, etc.
Is there a way/software tool/framework to simulate virtual users for this app that can send requests to the AWS servers pretending to be from different accounts/apps?
The simulator should send requests just like my actual iphone app would send if I were to add an item to the list or delete or edit.
I understand stress testing is a well established topic but here I want to just simulate multiple users and demonstrate scalability instead of trying to push the Web service to its limits. Neither am I sure if this completely overlaps with traffic simulation.
Any help will be deeply appreciated.
You might be able to do it using Apache JMeter. That depends on what you have going on on the backend. But it supports the following server types:
Web - HTTP, HTTPS
SOAP
Database via JDBC
LDAP
JMS
Mail - SMTP(S), POP3(S) and IMAP(S)
Native commands or shell scripts
You should be able to wire something together with that.
http://jmeter.apache.org/
http://www.opensourcetesting.org/performance.php
I've used it at various points to simulate VERY heavy loads for my services running in AWS/EC2.
Apache Benchmark is a very convenient tool for doing HTTP load testing -- you can have it make concurrent requests to simulate multiple users. It's main advantage over other tools is that it's simple and easy to get started with. If your backend listens on HTTP, it might be worth trying ab before investing any time in something more complex.
I got a project using GWTP (which involves MVP separation, Gin and Dispatch), now I'm on the situation where it is required that changes on the server are pushed to specific clients
I've reading the gwt-comet and gwteventservice documentation, It seems the first doesn't work with RPC and the second Ecnapsulates RPC, for which I don't know how to fit it in my current command pattern from GWTP. Ideas?
I have been using gwt-comet (http://code.google.com/p/gwt-comet/). It's a native comet implementation working pretty good like RPC, you can send Strings or your GWT-serialized objects as well. And the best thing you don't need to do many things to make it works.
i used "Server Push in GWT" described here http://code.google.com/p/google-web-toolkit-incubator/wiki/ServerPushFAQ - it seemed to work fairly well for a small project.
This is really a servlet problem, not a GWT or GWTP problem.
So there are a few approaches to doing this, the most stable (in my opinion) is to have a long or blocking poll servlet. This is basically a servlet that is polled by the client, and holds the connection open for some period of time if there is no message to 'push' to the client, and if too much time passes (this is to get around http timeouts) a heartbeat is returned of some kind. Either way, when the servlet request request returns, the client just makes another request. This is the most portable and stable way to my mind, since it uses only the core servlet api, doesn't suffer from network issues, and the blocking portion allows you to have the poll 'park' at the server for some period of time and reduces total request load, while allowing very quick return of new information to the client when there is some available.
The next way to achieve this is via WebSockets, this is great once you get it working and in my opinion is the way of the future without question. I think this is a good one to work with since this will be, in my opinion, a paradigm shift in web applications once it catches a head of steam, so we all need to be up to speed. Basically, you have a javascript 'socket' open via port 80 (this is one of the best features, since you don't have to open any firewall holes) and can communicate in two directions across that socket.
Comet can also work, but it will generally lock you down to one server type, which may be alright for your application. Caveat here!!!! I have only done very small tests with comet, it was flaky for me when I set it up, and was not as steady as the blocking poll solution as I had it set up.
Now the neatest one in my opinion, but this one is very limited due to network constraints probably to single domain intranet applications, is to use an applet based push. This setup (which could be done with udp or a straight socket, I did all web just to keep it all simpler conceptually) takes the applet, uses it to spin up a jetty server instance on the client, and the has the page publish the client's jetty 'endpoint' to the server. At this point, the client can contact the server using it's servlets, and the server can contact the client at the servlet(s) exposed on the jetty server. This is true push, it's neato, but there are network nightmares.
So of all the above, I use long polling, keep my eye on web sockets since they are the future in my mind, and really like the applet based version, although it's quite restricted in use due to the network resolution limitations.
Once you have this decided, from GWTP you would just have actions or JSNI bridge methods as needed to connect to your server and receive responses. I won't go into this, since this is really a core servlet/http/javascript question more than a GWT or GWTP centric question.
I hope that helps!
I'm looking for advice on the best way to implement some kind of bi-directional communication between a "server-side" application, written in Objective-C and running on a mac, and a client application running on an iPhone.
To cut a long story short, I'm adapting an existing library for use in a client-server environment. The library (which runs on the server) is basically a search engine which provides periodic results, and additionally can provide updates for any of those results at a later date. In an ideal world therefore I would be able to achieve the following with my hypothetical networking solution:
Start queries on the server.
Have the server "push" results to the client as they arrive.
Have the server "push" updates to individual results to the client as they arrive.
If I was writing this client to run on another Mac, I might well look at using Distributed Objects to mask the fact that the server was actually running remotely, but DO is not available on an iPhone.
If I was writing a more generic client-server application I would probably look at using HTTP to provide some kind of RESTful interface to searches, but this solution does not lend itself well to asynchronous updates and additionally what I am proposing does not fit well with the "stateless" tennet of REST: I would have to model my protocol so I "created" a search resource that I could subsequently query the state of and I would have to poll for updates to it.
One suggestion someone made was to make use of something like BLIP to provide me with a two-way pipe between the client and the server and implement my own "proxy" type objects for the server-side resources that knew how to fetch data from the server and additionally were addressable so that the server could push updates to them. Whilst BLIP provides the low-level messaging framework needed to communicate bi-directionally it still leaves me with a few questions:
How will I manage the lifetime of the objects on the server? I can have a message type that "creates" a search object, but when should that object be destroyed?
How well with this perform on an iPhone: if I have a persistent connection to the server will this drain the batteries too fast? This question is also pertinent in the HTTP world: most async updates are done using a COMET type hack which again requires a persistent connection.
So right now I'm still completely unsure what the best way to go is: I've done a lot of searching and reading but have not settled on any solution. I'm asking here on SO because I'm sure that there are many of you out there who have already solved this problem.
How have you gone about achieving real-time bidirectional networking between the iPhone and an Objective-C server-side app?