I have a year's experience writing client code but none with server stuff. I want to restrain the question a bit so I'll simplify what I'm trying to achieve.
I want to write server code such that two clients (Browser or iPhone / Android) can connect, when two player have connected they see a timer count down to zero. The clock would be synchronize on the server and the clients would be uniquely identifiable.
The trouble here is with the word connect, what do people use for multiplayer games? Open a TCP socket for two way communications? You can tell I'm not really sure what I'm talking about. I was hoping to use AppEngine but I'm not sure if it's suitable as it's request based.
I have some experience with Java and although Erlang sounds like the best choice this is something I just want to play with and push out fast so Java would be easier. I just need to know the best way to connect players etc.
Thanks,
Gav
I suggest we regard desktop and mobile systems as equal clients. What options are then?
You write a socket server which will accept connections from clients. But then you need to write some socket client as well, even 2x - for a desktop and for a mobile OS. And the user will have to install this client.
You launch a web server (whatever technology you like). It will expose some web services which will be equally accessible to both desktop and clients OSes. But still you need to write a client application (again 2x).
You run a web server and make all functionality accessible via standard HTTP protocol. This way you won't even need a client - almost every desktop or a mobile OS has at least some web browser installed. JavaScript will provide for dynamic updates of your ticker.
There is a good series of articles about Networking for game programmers by someone who does that stuff for a living.
I'm by no means an expert on network communication, but if you don't mind loosing a few packets (or error checking in software) and you want fast, lean communication you could use UDP. I think most time-sensitive data programs and streaming media use this protocol to avoid delays and keep packet size down.
I realized a Client/ Server app a few years ago with java and ServerSocket (http://java.sun.com/j2se/1.4.2/docs/api/java/net/ServerSocket.html). You also have a SSL version.
So you create a ServerSocket and wait for connexion. When a client is connected, you create a thread that will discuss with this client with a protocol that you made.
http://www.developer.com/java/ent/article.php/1356891/A-PatternFramework-for-ClientServer-Programming-in-Java.htm
If found this little framework :
http://www.bablokb.de/jcs/jcs.html
One of the hardest thing is to create your protocol , a good way to learn how to create one would be to understand how work the FTP (or HTTP ...).
You are correct that the J2EE model breaks down with near-realtime or multi-player demands. You migth want to consider the RedDwarf game server project. It does for games what Servlets do for busienss logic and is open source.
http://www.reddwarfserver.org
I suggest we regard desktop and mobile
systems as equal clients. What options
are then?
RedDwarf has a pluggable trabsport layer and can support any sort of client you wish.
Web servers are great for web type apps. if your game acts like a web page-- is not multi-user, is turn based, and evolves very slowly-- then a web server is a fine chocie.
If it doesn't however, you need something a bit beefier in technology.
Oh, and for what its worth, whetevr you do, if you want to write a server from scratch then DON'T use"ServerSocket." That requries a thread per connection and will never scale. Use NIO or use an NIO framewoprk like Netty.
Related
For a hobby project of me i'm looking to implement a group voice chat feature. Pretty straight forward: I'm running a server to which multiple clients (mobile) can connect to. Some Clients are in the same "group" and I want them to have an audio chat feature.
I already set up a UDP server client with C# to which clients can connect to. I have successfully implemented audio distribution between clients over the server and the rudimentary features are working pretty well.
I am not sure if i'm going in the right direction with this approach though.
I'm stuck with the implementation of mixing the different voices for example (two people talking simultaneously and another is listening to both). I don't really know how I can mix both voices together and generate different outputs for different clients - above mentioned example: The two people talking should only receive the input of the other person while the one not talking should receive a mix of the other two talking.
What is the best server sided structure for this? Should i maybe go in a completely different direction and work with SIP? I'm having a hard time finding suitable resources for this problem online and i'm really stuck.
Thanks for your help!
Let me suggest using standards in your application. If (as I strongly recommend) your application is a web application, WebRTC make your job dramatically easier. Please see in WebRTC samples some ideas that I'm sure will inspire you, including multiple peer connections
If you are only interested in group calls, you could install a PBX server as asterisk that has a powerfull set of conference capabilities. You could use a SIP library on top of WebRTC in clients (e.g. sip.js, sipml5) to connect via SIP to asterisk and obtain conference services. This could sound daunting but the code for calling a conference room can be reduced to very few lines and asterisk can be easily installed in a linux box in a real machine, or in a virtual one or in a docker container.
If you prefer fat clients, I suggest using a SIP library as PJSIP (that incidentally is the base of the new SIP stack for asterisk). Proprietary solutions ride against the future while standard ones are pushed by it.
I need to create a server that will receive an encrypted/signed message in form of a http request (Google App Engine), decrypt it/check the signature, and send it over a TCP/IP connection (Bitcoin network). Moreover, it will need to do the same in reverse - receive TCP/IP messages, encrypt/sign them, and send them as a http request. I'm planning to put the server on EC2.
I don't have too much experience with these things, so I'd like to ask - what is the easiest programming language to create something like that in, and what libraries would you recommend for the required usability?
If this is your first time doing something like this, I would suggest keeping it simple. Do you really need part of your system running on App Engine and part on EC2? For a newbie developer I would suggest sticking to one or the other. If you really need TCP/IP sockets, this will mean EC2 only. App Engine can not do arbitrary TCP/IP networking - you can only communicate via http and https. (note that I am unfamiliar with bitcoin's details - perhaps it can operate just fine over https)
When it comes to picking a programming language and web framework, if you don't have any experience at all yet, you might want to find out what the best bitcoin libraries are written in, and start there.
I am building a silverlight app and would like to add p2p capabilities - allowing users to send each other data.
Is it available out of the box?
Should I wait for silverlight 4.0?
Do I need a p2p server?
The key problem is actually opening the client-side socket to accept connections from another machine, and Silverlight doesn't support this, even in out-of-browser mode, and even in Silverlight 4. If you wanted to do something like this, as the other folks have mentioned, you need a common server that both clients can connect to and which will proxy the messages back and forth between clients. And of course, the fact that Silverlight sockets are limited to ports 4502-4532 also means that you're somewhat limited by firewall policies.
What we've done with our applications (using Silverlight 4) is to try to connect with the new support for Net.TCP (which scales much better), and then if that fails, fallback to the HttpDuplexBinding (which runs over HTTP and hence is more likely to make it through a firewall). We then wrote a WCF service which receives messages from one client and submits them to other subscribing clients. It's not P2P, but it allows for a similar result (apart from all the actual benefits of P2P connections).
If you move to WPF, you give up on the portability of Silverlight, of course, but you get full server socket support, along with the ability to code various NAT traversal strategies like STUN and TURN.
I don't think you could make this work in Silverlight with a serverless environment.
You could probably do whatever you're looking to do with a server and a web service, although this technically wouldn't be a peer-to-peer application anymore. You'd have to send your messages to the server, and the server would then send to the appropriate client(s). If you follow this route you might also want to look into WCF RIA Services for Silverlight as it has built-in support for things like authentication.
EDIT -- I don't know if this is an option but it looks like someone has come up with a way to do P2P in Silverlight. However, it requires that you run the app in Windows Live Messenger:
http://www.codeplex.com/SilverlightP2P
I wanna build a Win32 app of Client/Server (or 3-tier) type with follow features:
When the "A" client does a modification (update,insert, etc) into a database, the rest of clients viewing the same record set can get almost "instantly" a fresh view of this data
a client can be notified when a connection to database get lost
could someone help me? Thanks in advance
Pdta: My Database is MySQL 5.1
Note that by doing this, and having lots of clients, you will potentially get a lot of network traffic.
This is exactly the reason that most client-server applications do not do this.
If you really want to do this, then the proper was is to implement the 'observer pattern'; a basic example on that design pattern in Delphi has been described by Joanna Carter in her blog.
Then you need to extend that pattern so it works over a network.
So at least you need some server process that handles the "subject" interface.
You can use anything for that: WebServices, DataSnap servers, RemObjects SDK, etc.
Most people wanting a solution like this, go from the traditional client/server application into a multi-tier application. Then the middle-tier can handle all the notifications for you.
My answer depends on your network architecture but I tend to use IP for this type of thing. Something like Multicast is an ideal way to notify all clients on the Network of an event. Simply multi-casting or broadcasting (UDP) the ID of the updated record may be all that is required. If another client is interested in the record, it can then refresh it from the Database.
The Indy Multicast Client/Server components will provide a simply way to implement this in your app.
If you have a three tier type application, the client communicates with the aplication server. This connection could use callbacks to the clients to notify them about important events. DataSnap supports callbacks (afaik also data change notifications).
If you build your own application server. the client could open a socket connection to the server (in a thread) and listen for event notifications. The Indy Telnet client example in Protocols/IdTelnet.pas is a good starting point to create a very simple notification implementation. It uses the TIdTelnetReadThread class to listen for the server responses to key input and protocol negotiations.
If your application needs to run in Terminal Server environments, where Ports will not be virtualized AFAIK, it is safer to connect from the client to the server (instead of opening client socket ports for peer-to-peer communication).
If MySQL doesnt support somekind of pushing info or attatching clients you would need to use a middle tier running on a server.
That server keeps track of connected clients. But it would probably be a heck of a job.
I know that the "bigger" edititions of Delphi has somekind of support of building this kind of client/server software.
I know it has nothing to do with your application, but Firebird has a nice feature to do exactly this. You can read more about them here (link to a PDF).
Now, if you need to do this with MySQL and Delphi, the easiest way I can think of is doing something "AJAX LIKE" on your Win32 app. That is having a server side app (you could use a WebServer with PHP, Java, .NET or whatever you want) that will serve your requests asking for data updates. On the server side app, just do a query asking for modifications into your MySQL Database.
Hope it helps.
I have a need of implementing two apps that will exchange data with each other. Both apps will be running on separate PCs which are part of a LAN.
How we can do this in Delphi?
Is there any free component which will make it easy to exchange data between apps across PCs?
If I'm writing it myself, I (almost) always use sockets to exchange data between apps.
It's light weight, it works well on the same machine, across the local network or the Internet with no changes and it lets you communicate between apps with different permissions, like services (Windows messages cause problems here).
It might not be a requirements for you, but I'm also a fan of platform independent transports, like TCP/IP.
There are lots of free choices for Delphi. Here are a few that I know of. If you like blocking libraries, look at Indy or Synapse. If you prefer non-blocking, check out ICS.
Before you choose a technique, you should characterize the communication according to its throughput, granularity, latency, and criticality.
Throughput -- how much data per unit time will you need to move? The range of possible values is so wide that the lowest-rate and highest-rate applications have almost nothing in common.
Granularity -- how big are the messages? How much data does the receiving application need before it can use the message?
Latency -- when one aplication sends a message, how soon must the other application see it? How quickly do you want the receiving application to react to the sending application?
Criticality -- how long can a received message be left unattended before it is overrun by a later message? (This is usually not important unless the throughput is high and the message storage is limited.)
Once you have these questions answered, you can begin to ask about the best technology for your particular situation.
-Al.
I used to use Mailslots if I needed to communicate with more than one PC at a time ("broadcast") over a network, although there is the caveat that mailslots are not guaranteed.
For 1-to-1, Named Pipes are a Windows way of doing this sort thing, you basically open a communication channel between 2 PCs and then write messages into the pipe. Not straight forward to start with but very reliable and the recommended way for things like Windows Services.
MS offer Named Pipes as an alternative way of communicating with an SQL Server (other than TCP/IP).
But as Bruce said, TCP/IP is standard and platform independent, and very reliable.
DCOM used to be a good method of interprocess communication. This was also one of Delphis strong points. Today I would strongly advice against using it.
Depending on the nature of your project I'd choose either
using a SQL server
socket communication
Look at solutions that use "Remote Procedure Call" type interfaces. I use RemObjects SDK for this sort of thing, but there are open source versions of RealThinClient which would do just as well.
Both of these allow you to create a connection that for most of your code is "transparent", and you just call an interface which sends the data over the wire and gets results back. You can then program how you usually do, and forget the details of sockets etc.
This is one of those cases where there really isn't a "best" answer as just about any of the technologies already discussed can be used to accurately communicate between two applications. The choice of which method to use will really come down to the critical nature of your communication, as well as how much data must be transfered from one workstation to another.
If your communication is not time sensitive or critical, then a simple poll of a database or file at regular intervals might be sufficient. If your communication is critical and time sensitive then placing a TCPIP server in each client might be worth pursuing. If just time sensitive then mailslots makes a good choice, if critical but not time sensitive then named pipes.
I've used the Indy library's Multicast components (IdIPMCastClient/Server) for this type of thing many times. The apps just send XML to each other. Quick and easy with minimal connection requirements.
Probably the easiest way is to read and write a file (or possibly one file per direction). It also has the advantage that it is easy to simulate and trace. It's not the fastest option, though (and it definitely sounds lame ;-) ).
A possibility could be to "share" objects across the network.
It is possible with a Client-Server ORM like our little mORMot.
This Open Source libraires are working from Delphi 6 up to XE2, and use JSON for transmission. There is some security features included (involving a RESTful authentication mechanism), and can use any database - or no database at all.
See in particular the first four samples provided, and the associated documentation.
For Delphi application integration, a message oriented middleware might be an option. Message brokers offer guaranteed delivery, load balancing, different communication models and they work cross-platform and cross-language. Open source message message brokers include:
Apache ActiveMQ and ActiveMQ Apollo
Open Message Queue (OpenMQ)
HornetQ
RabbitMQ
(Disclaimer - I am the author of Delphi / Free Pascal client libraries for these servers)