My question is very brief - In the Zephyr documentation, I couldn't find an answer to my question (which surprised me). Is it possible for a GATT Client to connect to more than one GATT Server?
Right now I am using two boards to compute something (one as a server and one as a client). Ideally, the result of the computation should be written to a characteristic on a third device, another GATT server.
You're right I couldn't find this information easily but it is certainly possible to have multiple connections as I've tried this myself before. Many application and products built on Zephyr also rely on this feature. Generally speaking, there is no limit to the number of BLE connections that is imposed by the Bluetooth specification, but the limitation is usually dictated by the hardware. This is somehow mentioned in the Zephyr link below:-
https://docs.zephyrproject.org/latest/guides/bluetooth/overview.html
I hope this helps.
I'm looking to write my own multiplayer game server (most likely in nodejs) and I was wondering what protocol I should be using to transfer data? Are Datagrams the norm to send information (i realize they don't confirm delivery like HTTP, that can written on top of the protocol)? Any suggestions of performant proven systems would be a real help.
I guess I'm looking for successful techniques in handling the data transfer quickly and effectively (maintaining state on the server and scaling are a separate issue that I have a solid understanding of).
I'm looking to initially support desktop/mobile games (MacOS, iOS, and Android).
For all your protocol needs take a look at socketIO.
Basically your best solution is to rely on websockets which are TCP sockets. socketIO is just a nice cross-browser compliant abstraction.
Either you use standard long pulling techniques or html5 websockets. There is no access to UDP for browser <-> server.
There is a technology that is called RTMFP that Adobe introduced in the latest version of Flash (Flash 10). It allows you to do P2P connection and transfer data directly from a client to an other client without passing by the server. On top of that, it's using UDP to transfer data. I believe that this was originally designed to do video and audio streaming, but you can use it to pass data around.
However the main downside on this technology is the mobile since most of them don't support Flash. In this case you can use Socket.IO and use the server as a router of information as a fallback.
If you want to build your application in Javascript, you can still use it by bridging the functionnality to Javascript. If you want to take a look at a simple version of a bridge, you can take a look at this github project (I am the author).
As a C++ developer of Massive Multiplayer games for 10 years, I can tell you that most of your more advanced games, such as ones in which I was involved (Legends Of Kesmai, Magic: The Gathering Online, Airwarrior II, AVP, NTN Triva) to name a few, TCP is used for most communication simply because you need an ACK / NACK to be sure the data was received from the client. That is not to say UDP doesn't have it's place. In Legends we wrote the the protocol code to use UDP for out of bandwidth delivery of data which wasn't imperative that it be received in proper packet order and complete. Use UDP when you want to do things like update graphic files in the background while the user is playing, etc. This type of delivery is often used for such purposes and allows your TCP packets to arrive as required by your server.
Is it possible to create a real time game with node.js that requires twitch reflexes. How high is the latency? How low can it realistically go?
It is possible to make a real-time game in node.js as you could with any other language/framework.
The problem here would be what kind of server and client you would use.
Using the http server feature for such game would be a bad idea and very difficult, but you could use the TCP server (now called net server) as you would in any other language.
The client would be on some platform where you can use sockets, like Flash, Java applets or desktop software.
Please notice that even with using a TCP socket server you might have problems with latency for a twitch game, but this is outside the area related to this question and more about games and networking.
PS: You could use web sockets since they should theoretically work like TCP sockets but there isn't yet a good support for them in the current modern browsers.
EDIT:
It seems I haven't explained myself correctly, you can make a browser accessible game like you said, you just need to use a protocol that allows you to quickly send data back and forth in real time.
If you want a "pure" browser game without any third party plugins the only way, like I said before, is using JavaScript with websockets which is not well supported yet by the major browsers. (You could use a Flash bridge and still have your game in JavaScript though.)
Using a third party plugin you have Flash and Java (besides the numerous less known plugins like unity and so on). Both have TCP sockets (not sure about UDP) and can be made to connect to a node.js net server (with some security limitations). Most people would say for you to go with Flash since there is a bigger support but Apple doesn't like it so no Flash in iPhone/iPad/iPod Touch or on other miscellaneous mobile devices (that support Java instead).
So yeah... good luck with this.
EDIT 2:
Websocket support in browsers is now pretty decent so I recommend it for realtime games if you want to use the browser as a client.
HTTP servers are typically optimised for throughput/bandwidth over latency. node.js is unlikely to be an exception, and HTTP is intrinsically poor for low latency anyway due to the structure of the protocol.
One informal benchmark using node.js supports this, showing latencies of hundreds of milliseconds. By comparison most twitch games support latencies of no more than 30 or 40ms, ideally less.
Therefore I'd recommend dropping the twitch aspect if you can't drop HTTP.
It's possible, but it depends on how much data must be transmitted between server and client and how fast (speaking of latency). Take a look at Sousaball by Creationix, for example.
Also, if you plan to use websockets, take a look at Socket.IO library by learnboost. It uses websockets when available and falls back to comet in other cases.
The GameKit in iPhone SDK 3.0 create a peer-to-peer bluetooth connection between two iPhones, using Server-client model. In the bluetooth spec, up to 7 clients can be connected to a server. But in GameKit document, there is no words for this issue. Does it means a GameKit server can connect more than 7 clients? If yes, does that mean some clients is in sleep mode?
Thanks!
I've been looking for a definitive answer for this for months. There isn't one as far as I can tell. I keep going back to Volcore's blogs on the "woe's of gamekit" where they detail getting up to 4 devices connected over Bluetooth with very unreliable results. All Apple's demos point to "two devices connected" to be the ideal GameKit situation. I eschewed BlueTooth in favor of Wifi in the game I am developing since I knew that I could definitely get more connected (I needed up to 6 players—wasn't convinced I could make it work with BlueTooth). I've found it to be no problem to get 3 devices and simulator talking to each other (though It's not a real-time game—it's turn based—so the data sends are small and infrequent). My guess is that GameKit over bluetooth would not support more than 7 clients.
I've been working on a little app to broadcast messages to multiple iPods. It seems rather unreliable to use bluetooth for any more than two clients (assuming you're setting up a client-server architecture). I'd recommend using cocoaasyncsocket for communicating with multiple clients. I think you'd need a router though.
Recently I started developing a J2ME app prototype. I noticed how difficult it is to develop a good looking UI. Consider developing an app in J2ME for booking flights interacting with webservice.
A website to book flights will be easy to develop with nice ui and can be accessed by browser on a handset. I understand not all handsets have browser but all the new and upcoming ones have browser and have big screen as well.
Is it a good idea to develop such a application in j2me which need to talk to webservice for it to work? Or j2me is only suitable for standalone apps?
Advantages of J2ME:
Can access phone resources, like file system, phone book and GPS. The last is very important in map applications.
You can build richer User Interfaces. It may be difficult as you say, but there are many GUI libraries that could assist you. On the contrary the UI for a mobile browser (you can't rely on CSS and javascript working) would be very poor.
Greater flexibility on the communication logic. You can encrypt/decrypt data, compress them, use SOAP web services. With the browser, your best bet would be to develop REST services.
Disadvantages of J2ME:
Midlets need to be signed. This has some cost and there are situations that even a signed app won't run properly in specific phones.
Developing a midlet to run in all types of phones is a nightmare. On the contrary, a well designed mobile web application would be displayed properly in all recent phones.
You need to have a channel for distributing your application. People would need to download it and get charged for the required bandwidth. You would need to care for angry customers having problems with the application. Things are easier with a web site.
J2ME apps are inevitably compared with native applications (iPhone, Windows Mobile, Symbian). Compared to these, they are very poor and many would find that paying for them or even using them isn't justified.
My conclusion: Nowadays real smart phones are becoming more popular and win an ever growing market share. Under these circumstances, the advantages of J2ME can't really overcome its restrictions. The only exception I could think of, is if to have to develop a GPS application. For all other cases, a mobile web site is a better idea.
There are a lot of misunderstanding and plain wrong statements in the previous answers.
I advice you to just do your research yourself. Nowadays you CAN develop really good looking apps with J2ME without writing your own GUI framework. Take a look at LWUIT really. For example they have a virtual keyboard as one of their touch screen functionalities and this you have on devices like the N97 which itself does not have a Virtual keyboard. BTW using LWUIT you have a Blackberry and Android port included if anyone cares.
Also Apps nowadays become the center stage on many platforms not just the iPhone. Look at the recent developments in this area like OVI, RIM, Samsung, SE, Orange World they all start with app shops.
"Getting people to use a website on their mobile phone is easier than getting them to download an application." this is just a claim without proof. you cannot say that like this. It depends on a lot of other factors. - Why should users type in your mobile url into the rather small screen again?
Anyway, this answer is probably too late so I'm not gonna write much more. The mobile industry is changing fast right now but there is not yet a alternative to J2ME for crossplatform development. Maybe in the future with better browsers and widget technolgies.
Just a short note, applications like google maps or gmail mobile probably don't use WebServices to talk to their server part. A WebService has a lot of overhead, especially when considering that mobile users are usually rated by the amount of data they transmit. The best way to perform communication between your client app and its server part is to use binary data over a socket connection.
I personally think it's really hard to make a consistent and reliable J2ME application that will run across a large set of mobile phones. Based on my experience, I would only develop a J2ME application (instead of a Web application) if it's a strict requirement - for example, to be able to view your bookings without being connected to the network. There are other costs associated with J2ME applications - the applications must be downloaded, the user will be asked if the application is allowed to connect to the network when it attempts to (there are exceptions for this case but I believe the application has to be signed by 3rd party company - more $$$ involved), you will have to maintain different versions of the application running on a variety of mobile phones (more complexity to the application), and so on...
Think about it this way - if you were developing a similar thing for a computer, would you build a desktop application or a web application? With the cellphones of today (many of which can access full-html sites with javascript - which means ajax), the proposition of the question is valid.
I thing a good rule of thumb should be: If what you're trying to achieve can be done with a mobile website - go for the website.
IMHO, apps should only be used to if they cant take advantage of the mobile hardware - like location, sound, video, 3d, pictures etc...
Even if the dev costs for the app were insignificant (they usually aren't), you'd have to offer some really amazing capabilities to make the users go through the trouble of downloading it.
(All of this is essentially true for J2ME/BREW. The iPhone is a little different as apps take the center stage)
One thing worth highlighting: the only standard way of deploying a MIDlet is via OTA download so you wouldn't expect a J2ME-capable phone to not have a web browser.
Mobile web browser like Webkit and Opera are getting better faster than J2ME (at least until MIDP3.0 starts shipping, if ever).
No matter which platform you choose, you will need to test your service on many devices. I don't think switching from J2ME to webapp makes a huge difference in that regard, because phone manufacturers keep changing the binaries that go into the phones firmwares.
Getting people to use a website on their mobile phone is easier than getting them to download an application. unless that application is already installed when they buy the phone, that is.
You might want to look at LWUIT for better and easier J2ME GUI.
One thing that J2ME will accomplish for a flight booking service is save battery life by not requiring constant network data transfer, thanks to the local storage mechanisms.
there are many great j2me apps that (need to) talk to webservices. just think of the google apps, like gmail mobile and maps for mobile. they are faster and easier to use than using the services via cell phone browser. so if you can design a good app, it's definitely worth it.
EDIT: also, a j2me app makes possible features that can't be provided by a web application: integration with phone features (address book, calendar), "call this number", location api, etc.
I think for business apps, or more text/data oriented things, a mobile web/wap site might be easier to maintain, since you won't have to deal with pushing client updates out to handsets.
For UI-intensive apps (maps, games, etc.), client apps are probably the way to go, so you can handle the more of the processing and rendering on the client side.
Both options are difficult though, since there are so many compatibility issues with phones. You might be best served by narrowing down what types of phones you want to support for your app. If you think most of your customers will be iPhone or Android phones, you can target those platforms (with either client apps or web apps) and avoid old-school j2me completely.
I hate WebApps on phones. They are slow and they don't work in a semi-connected environment.
J2ME apps can do local backups, bluetooth backups, bluetooth data sharing between 2 phones and better responsive UI. However that requires money,skill,time etc.
My main gripes with MIDP though is pushing software updates and wav real time mixing. Technically those are possible within the scope of MIDP but the goons at wheel are not very creative.