I want to write an app in java that lets two clients talk via webcam. The way it works is both clients connect to a webcam that takes pictures at a specified frame-rate (20 per second maybe) then reduced the size and resolution, then sends it to the other client via a UDP packet. My question is - should I send every picture in its own Datagram Packet? I've read that they can only hold half a kilobyte at most so should every pic be cut down that much? Or should I have it split up into several Packets?
Are you sure you want to transmit whole images, instead of using an algorithm / codec that transfers only what needs to be updated?
If you choose the second option you can take some ideas from this previous question and a already used and tested library for the purpose. I believe i'd go with VLC java bindings if i had to do it. You should evaluate what is the best codec for your specific purpose (bitrates, quality, etc).
If you nevertheless want to transmit images i'd suggest you break them down into udp datagrams, remember that they should be somehow numbered/tagged so that the client can reconstruct the image as packets come (they won't necessarily come in the same order you send them), also you need to think what the client needs to do when some of the packets fails to arrive (discard the image, request previous packet, etc.).
One last thought, the udp datagram max size might not be the best option as well, your server-client should perhaps implement a algorithm and negotiate the udp frame size depending on the speed of the transmission.
What you should be doing is encoding a video stream. Leave the network layer alone, let it do fragmenting for you.
Also, if you are sending video over UDP, you will likely want to throw in a keyframe every 2 seconds or so.
Do not send each frame as its own image. Use a video compressor.
Related
I want to capture packets from a crowded network and classify it by user request. I use java and jpcap for capturing packets. now I'm using array threads for each req packet. it's realy slow and there is many conflicts among threads. what's the best data structure for this purpose?
after that, I'm saving packets (req/response) into a file, that is very slow for such a heavy work. what should I do for saving my datas?
thank you
I'll need some example code to help you with the first part, because your question is a little vague. what's the best data structure for this purpose? could be anything depending on what exactly you need that structure for.
The JpcapWriter is pretty fast. I need to capture roughly 330mb of raw packet data from a 2 minutes of capture, and I haven't had a problem with being able to write it to disk while continuing to capture.
I am making a game in java and it is going well. I want to early on implement multi-player so I build on it instead of porting the entire game to multi-player when it has a ton of different features..
I would like to make it a Client / Server application.
Now I'm now sure how or what to implement the multi-player. I have read the java tutorials about sockets and everything, I tested them and made a successful connection (in a test project). I am not sure where to go from here. I don't know how would I transfer for example where different players are on the map or even just if there ARE any player at all.. I don't know if to use a library or do it my self or what... If anyone could please either give me some kind of guideline on how would I transfer player data or anything like that though a TCP connection or maybe give me a library that makes it simpler..
This is pretty wide question and there are multiple ways to do things, but here's my take on it. Disclaimer: I am the server system architect of a mobile multiplayer gaming company. I don't consider myself an expert on these things, but I do have some experience both due to my work and hobbies (I wrote my first "MMORPG" that supported a whopping 255 players in 2004), and feel that I can poke you in the right direction. For most concepts here, I still suggest you do further research using Google, Stackoveflow etc., this is just my "10000 feet view" of what is needed for game networking.
Depending on the type of game you are making (think realtime games like first person shooters vs. turn-based games like chess), the underlying transport layer protocol choice is important. Like Matzi suggested, UDP gives you lower latency (and lower packet overhead, as the header is smaller than TCP), but on the downside the delivery of the packet to the destination is never guaranteed, ie. you can never be sure if the data you sent actually reached the client, or, if you sent multiple packets on a row, if the data arrived in correct order. You can implement a "reliable UDP"-protocol by acknowledging the arrived data with separate messages (although again, if the acknowledgements use UDP, they can also get lost) and handling the order by some extra data, but then you're (at least partially) losing the lower latency and lower overhead. TCP on the other hand guarantees delivery of the data and that the order stays correct, but has higher latency due to packet acknowledgements and overhead (TCP-packets have larger headers). You could say that UDP packets are sort of like "separate entities", while TCP is a continuous, unbreaking stream (you need some way to distinguish where one message ends and another begins).
There are games that use both; separate TCP-connection for important data that absolutely must make it to the client, like player death or such, and another UDP-connection for "fire and forget" -type of data, like the current position of the player (if the position does not arrive to another client, and the player is moving, there's not much point of sending the data again, because it's probably already outdated, and there's going to be another update in a short while).
After you've selected UDP and/or TCP for the transport, you still probably need a custom protocol that encodes and decodes the data ("payload") the TCP/UDP packets move around. For games, the obvious choice is some binary protocol (vs. text-based protocols like HTTP). A simple binary protocol could for example mark the number of bytes in total contained in the message, then type of data, data-field length and the actual data of the field (repeat for the number of fields per message). This can be a bit tricky, so at least for starters you could just use something like just serializing and deserializing your message-objects, then look at already existing protocols or cook your own (it's really not that hard). When you get the encoding and decoding of basic data types (like Strings, ints, floats...) working and some data moving, you need to design your own high-level protocol, that is actually the messages your games and server will be using to talk with each other. These messages are the likes of "player joined game", "player left game", "player is at this location, facing there and moving this way at this speed", "player died", "player sent a chat message" etc.
In real-time games you have some other challenges also, like predicting the position of the player (remember that the data the client sent could easily be hundreds of milliseconds ago when it arrives to another players client, so you need to "guess" where the player is at the time of arrival). Try googling for things like "game dead reckoning" and "game network prediction" etc., also Gamasutra has a pretty good article: Dead Reckoning: Latency Hiding for Networked Games, there are probably loads of others to be found.
Another thing that you need to think about is the concurrency of the server-side code. Many people will tell you that you need to use Java NIO to achieve good performance and using thread per connection is bad, but actually at least on Linux using Native Posix Thread Library (NPTL, pretty much any modern linux-distribution will have it out of the box), the situation is reverse, for reference, see here: Writing Java Multithreaded Servers - whats old is new. We have servers running 10k+ threads with thousands of users and not choking (of course at any given time, the sheer majority of those threads will be sleeping, waiting for client messages or messages to send to client).
Lastly, you need to measure how much computing power and bandwidth your game is going to need. For this, you need to measure how much load a certain (server?) hardware can take with your software and how much traffic your game causes. This is important for determining how many clients you can support with your server and how fast network connection you need (and how much traffic quota per month).
Hope this helped answer some of your questions.
First of all, multiplayer games use UDP for data transfer. There are a lot of reasons for this, for example lower lag and such. If your game contains intensive action, and need fast reactions then you should choose something based on UDP.
Probably there are solutions for gaming on the web, but it is not so hard to write your own implementation either. If you have problems with that, you probably will have problms wih the rest of the game. There are non-game oriented libraries and solutions on the net or even in java, but they are mostly not designed for something that fast as a game can be. A remote procedure call for example can contain costly serializations and generate much larger package, than you really need. They can be convenient solutions, but have poor performance considering games and not reglar business applications.
For example if you have 20 players, each have coordinates, states, and of course moving object. You need at least 20 updates per second to not have much lag, this means a lot of traffic. 20*20 incoming message with user input, and 20*20 outgoing message containing a lot of information. Do the math. You must compress all the players and as many object data into one package, as you can, to have optimal performance. This means you probably have to write small data packages which can be serialized into bytestream quite easily, and they must contain only viable information. If you lose some data, it is not a problem, but you need to take care of important informations to ensure they reach the destination. E.g. you don't want players miss a message about their death.
I wrote a reliable and usable network "library" in C#, and it is not a huge work, but it's recommended to look around and build it good. This is a good article about this topic, read it. Even if you use external library it is good to have a grasp on what it is doing and how should you use it.
For communication between VMs, it doesn't get much simpler than RMI. With RMI you can call methods on an object on an entirely different computer. You can use entire objects as arguments and return values. Thus notifying the server of your move can be as simple as server.sendMove(someMoveObject, somePlayerObject, someOtherObject).
If you're looking for a starting point, this could be a good one.
I am using a Java application to send UDP packets to an Android device. There I have another Java application that receives these UDP packets and displays its data - very simple.
Now I am working on some routing algorithms - therefore it would be nice to know how many hops a UDP packet did since it was send. My idea is to just read out the TTL (time-to-live) value of the packet and display it. Do you know if this is possible with pure Java? The class DatagramPacket doesn't give any hints at all.
I guess that this is not possible because this information might already have been removed at a lower layer, but I just want to be sure. :-)
The TTL field is, as you know, a feature of the underlying IP protocol (when used), not of UDP. So it makes sense for it not to be visible in the DatagramPacket API. However, I think you're right; it's not normally possible to get access to the IP packets through datagram-level API:s. You probably need to look into packet capture.
For your purpose, if I get it correctly, it would be sufficient to manipulate the TTL of the sender; e.g. set TTL of the sending socket to 1,2,3,4,5 and for each send one message with content "1","2","3","4" or "5" etc. Some will likely be missing on the receiver...
For my BlackBerry application, I am using a single thread to retrieve images from the server one at a time. My application has a number of images and it takes too long to load all the images. How can I speed this up?
If these are static images, you can also do something like CSS sprites - stitch them all together into one big image, then in code you display the portion of the large image that corresponds to the original image you want.
The last two arguments to Graphics.drawImage(...) indicate where to start drawing from the original image, and that's how you would select the part you want.
Use multiple threads instead of one. Also, if this is a server that you control, consider pre-sizing the images for the target devices or having the device send its size to the server to generate and cache device specific images.
its too late but sorry for that.
i have used observer pattern for it.
Link:-http://en.wikipedia.org/wiki/Observer_pattern
thankx
#Peter
Threads on a mobile phone is a bad idea. Firstly threading on phones suck! secondly phones can't really handle more then one http connection at a time stuff bombs out.
#Userbb
You can do sneeky things like stream them via a socket connection OR include multiple images in a single http request (creating a connection and http headers have overhead).
and also deff do what #peter suggested about resizing serverside.
An Android app I'm writing involves quite a lot of downloading of content (think podcatcher/RSS).
I would like to be able to give the user an indication of how many bytes they've downloaded, so they can make the decision whether they want to use Wifi or not.
To this end, I have found a way of counting the number of bytes read by the app, by wrapping an InputStream in a simple CountingInputStream.
However, this does not take into consideration basic things like packet headers and HTTP headers. More importantly, it does not take into consideration any compression that content may be encoded with.
So, how many bytes did my application download over the network? I'm not so interested in the number of bytes uploaded, but if know how, don't be shy.
I have gone down a fairly low level approach as I am feeding the input stream into an XML PullParser. I will also be needing to do a similar exercise with dumping bytes (images in this case) straight onto the SD Card.
Is this the best approach? What am I missing?
ufff... I think this is pretty transparent to underlying protocol, so you can't count all these bytes used in session or link layer, and operators like to charge even for control bytes which are not in any way visible to end user. Also they count traffic in both directions (your reqest to server takes also some), so - good question is: how to measure needed traffic/money for downloading that picture... ?
This isn't a direct answer, but you could try asking someone who has solved a similar problem before, e.g. a data counter application. I've used NetCounter by Cyril Jaquier (http://www.jaqpot.net/netcounter/), and he claims his software is open source. I couldn't get his download link to work, but there's a contact email address. If you got his source code, you should be able to use the same method as him.
As I know, there are two ways to count data traffic. One is /sys/class/net/{interface}/statistics as mentioned in android app named netCounter, the other is /proc/net/dev which is used in android app named wifi-tether. But I don't know the difference between these two methods nor which is better.
The number of bytes received by a particular app is stored in /proc/uid_stat//tcp_rcv where app_uid is the uid of your app on the particular device.