My Post is about Minecraft and its multiplayer servers. I will mention often the information, which is given on this website : https://wiki.vg/Protocol#Login_Start . So, my question is quite a bit complicated I guess. Please take care, that I´m not yet very familiar with Streams. I want to create my own "Chatbot" for Minecraft, which is able to join on every Server without opening the Minecraft launcher. But therefor my programm must receive and send packets.
I know about the protocol, which I mentioned above. In generell, there are 2 big steps of joining on a Server. The first is, to send a handShake and "ping-pong" to make a connection. The second step, probably the most complicated one, is to authenticate my account on this Server. I´m supposed to send certain information to the server and get some information back. Of course, I use DataInput/DataOutputStreams for sending and receiving. Now the protocol above plays a major role, because it says what I have to send to the server and in which form.
Java sending handshake packets to minecraft server
The post above was very usefull for the first step, to create a connection! In fact, somebody has made a lot of effort for this post, so I dont want to copy his code for my post. Please remember, that I used his code in my Project, so every line is the same (And his code works very well!). So, now you know everything about my situation, I ask the question how to send / receive packets with the information required to authenticate my client.
Hopefully you understood what i wanted to ask. Thanks for your time !
I'm not sure how much detail you're expecting from me, but all the packets you need to send to the minecraft server & the requests to mojangs authserver are outlined here.
As for the question & code you referenced, that's currently sending a handshake packet with nextstate set to 1 (status) which is only used for pinging the server, not connecting to it. You'll need to set that to 2 (login) & follow the sequenced outlined in the link above instead of just sending a request & ping packets.
Related
I made a web-server that runs on an esp32(LAN) and I have made it possible to send information to the esp itself from the servers url, (example : 192.168.1.39/?userInput=123), the number 123 is what I want to send from the application depends on the user's input (I compiled it to a packet of 8bits) so max number is 255, the server has an XML and some basic UI for viewing the information passed back and forth, I wanna be able to send the so called packet to the server and it passing it to the esp32 with almost no delay, I used google firebase before but it has way too much delay for it to be usable, I tried using a WebView and loading the URL with the number from the packet, I ran out of ideas on how to approach this would love some advice :)
I tried searching other questions here on the site, asked friends/teachers, watched a few tutorials and asked chatGPT for help but nothing was helpful.
From reading your question it seems you are lost setting up server and client at the same time. Divide the tasks into chunks you can digest:
First, setup your ESP32 webserver. Follow a tutorial like https://randomnerdtutorials.com/esp32-web-server-arduino-ide/ and test it using a normal web browser. It can be used to run GET requests easily, and the amount of data you need to transfer that should definitely be enough. Alternatively you can use curl to send client requests.
Next, develop your java client to send the appropriate request. You can test the behaviour using any standard webserver and check the logs.
Finally put the ESP32 url into your client and see whether they work together.
I have application Android to control computer (restart,shutdown,...) by connecting Android application with a Windows application (vb.net) through the Web Service
I do not know where to start and how to contact Anyone who has any idea on the subject ?
Since this is a broad question and you asked for ideas let me pour some thoughts.
Where to start? Define a protocol for the web service that both parties understand. For example define an URI that the android client can push messages to (with PUT or POST) and the vb.net client can poll for updates (with GET). Since we use one URI here the payload sent to the URI must define what to do. The android client could for example post the message '{command:restart}" then the vb.net client should know that he has to restart the machine if the message is received.
There are a few caveats here though. First the vb.net client needs to poll the URI to get the command. So between sending the command and executing it there is some delay. Even better, right now you don't even know if the command was executed or not. Also since there is no authentication everybody can issue commands to the web service. Sounds like tons of fun. For other parties at least. Lastly you need to clear the command from the URI if it was executed or updated. Else the machine would, in this example, go into a restart loop.
So the first problem may be solved with and extra URI where the android client can poll for some king of system state that the vb.net client provides. For example the vb.net client may send the message '{state:restarting}' to the URI before restarting. Of course the vb.net client needs to update that URI every time some event happens. The security issue? Security is hard. You may want to create a certificate and sign the requests sent so the server with it. Then the server can check if it was really you who sent this request. Or somebody that has your cert, replayed the request or found some way of breaking the whole stuff. So you additionally might want to use TLS with some king of certificate pinning. You might already know this but I'm going to repeat it anyway: do not send credentials over an insecure network. Also base64 (used in basic authentication) is not some kind of encryption. The last problem may be solved with a nonce that can be included in the command. Or the vb.net client clears the command from the URI (with DELETE) when it received the command. It should update the status URI though so that the android client does not send the request again.
Or you drop the whole web service stuff use technologies like Web Sockets. Then the android client can send a command to the socket. The server receives to command and sends it to the vb.net socket. When the command is received by the vb.net socket it sends out some kind of delivery receipt to the server and executes the command. The server receives the receipt and sends a confirmation the the android client so that it known that the command is going to be executed.
As you see there is a lot do do when implementing such a solution so let me summarize:
define you use cases. What operations must the system support and how are the participating parties involved in any case.
find corner cases for each use case. For example the authentication problem that needs to be solved.
do some research on technologies that support your idea at the best possible way. Maybe a web service is not the best solution? What is a web service anyway? (Seems to be some king of buzzword anyone uses). Maybe Web Sockets, XML RPC or even SOAP are better candidates?
define a protocol for the components
implement it
One last note. I know this is a rather long answer? that might spawn a lot of questions in the readers head. But, do not get discouraged! You don't have to do anything that I wrote here. Well except the security thing maybe.
I have a web-service on my server that pushes the xml data to the clients that are communicating to it over internet.
In these cases we have challenge to receive acknowledgement from the
client.
Specific case like, once client has received the data and before
sending the acknowledge, if the communication channel goes down.
Example:
In case of the software updates on clients over internet, how the server makes sure every thing is processed fine.
If you want to go on the "push" path, and you absolutely must know if the update was succesful, then you have to build your service and clients in such a way that you do know.
Basically what you need to do is build a small protocol so that information is transmitted no matter the failures of the communication channel. This means two things:
Your service does re-transmissions;
Your clients can deal with duplicate messages;
For example:
service pushes a message, client acknowledges => all good;
service pushes a message, the connection goes down, the message is lost. The client does not acknowledge since it never got the message => service pushes that same message once again at some later time. Now hopefully you get to case 1.
service pushes a message, client acknowledges but the connection fails and the service does not receive the acknowledge => similar to 2, so the service pushes that same message once again some later time and now the client receives the same message twice. It must ignore the second message but still needs to send an acknowledge so the service does not send it a third, forth, ... nth time;
And so on and so forth...
This is a high level description of what TCP does, for example. TCP is a reliable protocol over an unreliable network. It handles dropped packets, duplicated packets, etc.
Now, that would be pushing. A more simple alternative would be to use "pull" instead. The clients periodically pull the updates from the server. This is simpler to implement (the download is succesful if it worked, otherwise you try again later) but it's not without its gotchas, like for example:
controlling when clients start to pull data from the service. You can't just have them all update at the same time or you might overload the server. Clients should first ask the server if it's OK to update now or comme back later when the service is not so busy;
are you downloading upgrades in the background, from user devices? Data charges might apply so maybe it's better to ask the user if it wants the update now or later instead of doing it behind the scenes;
updating in the background, even if there is no problem with data charges might still consume bandwith when the client needs that bandwith for something else;
And so on and so forth...
The thing is this is a large topic, with general solutions that might not apply given particular situations. But it is not a new topic. Others have had these issues before. Consider for example Windows updates, how each PC's OS updates itself. Something similar happened a while ago when thick clients needed updates. The world moved to thin clients but now thick clients are making a comeback. Have a look at how these issues are solved, you will find usefull information online.
I do not think there is a way to do that. I believe the reason you are asking is for the following reasons:
1) If you are asking because you are sending a lot of data and your client deny receiving it, perhaps you can paginate it. That way you will know when the last page was accessed. You can even go one step further and just put very little data on your last page, that way you are sure that the last page is called.
2) If you are genuinely concerned about ensuring that they receive the entire data. How about suggest they access a 2nd web service which contains the checksum for the data, and suggest that they compare it.
Assuming that your web service is RESTful, your server should be stateless. The client should make sure it receives the data properly.
You could define a service to get the hash value of the data, followed by the request to receive the data itself. The client can check after the download whether the hash value of the downloaded data corresponds to the value received by the first call.
Amongst others, you could use MD5, SHA-1 and SHA256 in standard Java, as described in the Oracle documentation. This will calculate the hash value of the data from the server side.
Assuming you use Javascript from the client side, there are many possibilities to calculate the hash code using the same algorithms (jsSHA, for example).
I hope it helps.
I need to write an application in java which communicates with a web server.
I know how to do that, using PHP, but I'm afraid it won't cut it in this one.
Here's my situation.
I have multiple clients, when one of them sends a specific message to the server (so far, no problem on PHP), I want it to send a certain message to all other connected clients.
The problem is, I could hardly find any information regarding server socket in PHP, which led me to believe this isn't the proper way of achieving that. I'm using a paid hosting (x10premium) to host my servers so far, so I was thinking of doing it with this one, however, I'm not sure it's even possible with PHP.
At the moment I'm having each of the clients periodically check with the server if he received a message from any of the other clients, but I don't like this solution...
I hope someone could point me to the right direction. I don't know too much about Ruby and other languages which are used to do stuff like that, But if necessary, I would gladly learn it.
Thanks in advance
EDIT:
Forgot to mention, the server (currently the PHP) would also communicate with a MySQL table. If it matters.
This is a good example of PHP socket server/client:
http://tech.navarr.me/2010/07/how-to-create-a-socket-server-in-php.html
You could do it just like with JAVA, but remember that PHP does not support multithreading or multiprocessing so if 10 clients connect at once to your server, you will process them one by one, so eventually 1 will have to wait for the other 9 to finish - everything, database and connection overhead.
If you do it with JAVA or Python for example, you could handle each request in separate thread so that DB & Network communication overhead is handled simultaneosly.
Python has build in socket server components and nice and easy to use mysql component, that would make it a breez to achieve this, without even having to understand threading at all.
For the python socket server see here:
http://docs.python.org/library/socketserver.html
Basically you just define a function that will be executed for each new client connection and tell the server to serve_forever() - until it dies, it will do what you want.
I'm programming an Android multi-player game, which basically consist of a server where the clients connect and exchange messages. When the player connects to a server, a player list is return to him/her. A player can then select a user to challenge - of course he must select a player from the player list, which only contains connected users.
When a player1 challenges player2, a message needs to be transmitted from player1 to the server, which in turn must send a message to the player2, notifying him about the challenge. The player2 can then accept/decline the challenge.
I can use the following techniques to make this happen:
Use custom server/client with Java socket programming. The server basically accepts a connection from the client, spawning a new thread for each connected client. The problem with this are:
There needs to be a persistent connection open from client to server wasting battery life of the android phone. This is not really big limitation since the battery isn't consumed that much.
When I'll want to develop another game I'll have to rewrite the client/server code from the scratch - also choosing another port to listen for incoming connections - the whole concept gets rather difficult to maintain.
I'm also worried if this is the way to do it. Spawning another thread for each clients sound quite a lot if thousands clients are connecting at the same time. But I'm guessing the PC games do it like this. Not sure about android.
Use Java REST jersey to build the client-server on top of HTTP. This would be a perfect solution if the server could easily send notifications to clients. There are actually multiple design decisions here:
the client pulls the server for any new data/notifications every few seconds - this is really bad, since we're stuck with non responsiveness, delay, etc.
the client can send a waiting request to server, so the client receives the response only after some data becomes available. This is better, but can still produce a delay when two notifications one after another need to be sent to the user. The first notification is sent instantly, since the client already has a connection open, waiting for data to receive. But we would have to wait for the client to initiate another long http request to receive the second notification. The problem gets bigger as there are multiple notifications that need to be send in a row to a specific client.
the client can initiate a http streaming, where the communication is left open when the request is handled, so the server can also send multiple messages to client whenever it wishes. The problem here is that I don't know how well this works on Android. I've looked at several implementations:
Java jersey + atmosphere: didn't succeed in actually making it work. This seems the most promising, but I don't want to spend too much time on it, since I'm not even sure if it does what I want.
Deacon: seems pretty neat, but after seen the video tutorial on their official web page, I'm not sure that it can do what I need. When a player1 challenges player2, can it send a notification to player2 letting it know about the match request?
I would be glad to know how other multi-player games handle the network communications, if the two players are playing the game over the network.
I'm also open to a totally new suggestion how to achieve what I want. I can pretty much code anything, so don't hesitate to let me know of some more difficult way to achieve the network communication.
Let me also mention that I'll be glad to implement a totally specific method to work in my case, so it can be anything that will do the job done, but I'm also looking at more general way for communication between clients and server. So that I can program an interface/whatever and reuse the code in other android games, android applications.
I hope I presented the problem allright and that I'll receive some valuable answers.
Thank you
You should take a look at XMPP. It's a protocol (originally created for chat programs) that allows sending of xml data between users.
It has a separated client-server relationship, so that you can focus on developing a client application fit for phones, and a different server depending on your needs.
There are loads of information available on the protocol (I should know, I wrote a thesis about using the protocol in game applications), but you can start by looking it up on wikipedia to see if it is what you want.
aSmack is a library for creating android xmpp-clients. It takes some tweaking to set it up and get everything to work, but once you do, it's neat.
EDIT: relating to the answer suggesting using the C2DM:
from the c2dm docs "Sending large numbers of C2DM messages":
Are you sending C2DM messages too frequently? If you need to communicate with your application frequently over a short period of
time, C2DM is probably not the best solution. Instead, consider
implemeting XMPP or your own protocol to exchange messages, and use
C2DM only to send the initial notification.
It sounds like Android Cloud-to-Device-Messaging might be what you need
Push notifications without the app having to keep a connection open
I would vote in favor of some message passing technique - like activeMQ, rabbitMQ, zeroMQ eor something like it. On the server side you may stick with java , or javascript ( like
node.js ) - such solution would provide most performance and minimal latencies.
If latency is not that critical, you may as well use REST calls with JSON