I have a question:
I had created a client app in Android Studio, and I need to know if it will work if the server was on Windows as a GUI program using Java.
so if the server was made using java in GUI on Windows and the client as a app on a Android smartphone... Will they connect successfully to each other?
If both client and server comply with TCP protocol, they can interact with each other regardless of their underlying platforms, because all network protocols have their own principles and rules which must be obeyed by all platforms using them.
Also you shouldn't worry about medium-level byte ordering, because network has its own endianness which is big-endian and in various platforms they first convert their data to this endianness before sending it over medium. All these stuff are handled at OS level and you're not supposed to take care of them.
Related
I have an old java program that is communicating with an embedded device manufactured in 2000. The program communicates with this device using the standard Windows serial stack (from what I can tell, when I capture data using PORTMON in windows I see requests like IRP_MJ_WRITE and IOCTL_SERIAL_SET_RTS).
The device however, connects to a serial port on the computer using a Serial-to-Stereo Plug connector, similar to this. I believe this means the device itself is only capable of sending signals using two pins.
How can I analyze raw communication between the two devices in an attempt to reverse engineer the protocol? I am on Windows, but am capable of moving to OS X or *unix. I know at some point I am going to have to write something to deal with the specifics of how the device communicates, but what do you guys recommend for gathering information?
The stereo jack is just a cheap way to implement a minimal RS-232-based connection. That shouldn't affect monitoring.
Portmon should display the data you need to investigate the protocol. The IRP_MJ_WRITE requests contain the data sent to the device, while the IRP_MJ_READ requests contain the data sent by the device.
If you cannot do this by software interception means, a simple multi-channel logic analyze (such as one of the FX2 USB designs) should be able to capture traffic on both the transmit and receive lines, and then allow you to software decode this at leisure to see the full interplay of transmissions, responses, and any delays in between.
Hi i am learning java at the moment, specifically threading and networking which i have found to be very useful in improving my programming skills. i have a java program which consists of a server and a client using sockets. the server attaches a socket to each thread using start() method, and clients can write text which is echoed back by the server. I was wondering, and this seems feasible, if i could write another client in another language such as c++ and have both a c++ client and a java client connected to the echoServer? i am hoping to eventually have a very very simple application for windows written in java, and a very simple application for IOS, both connecting to the same server which is written in java
TCP/IP is a standardized protocol, just about every platform has an implementation of it. So yes, you can have a Java client and a C++ client and a C# client and a Pyphon client and any other client written in any other TCP-enabled language all connected to the same server at the same time.
I would like to be able to use a usb SmartCard reader/writer (NFC) using Flex but I cannot find out how to do it.
I know this approach does not seem the most secure, but I know that, for example, you can use with Flex a usb webcam if the users accepts to give that permission to the web application.
To give you a little background info about why I would need this: We have developped a web application which would be deployed in a local network of an enterprise and which server-side part is developped in java and which client side is developped in Flex. I have managed to use the reader/writer from the java part but that obviously is not practical as we can only use the tag reader/writer attached to the physical server. What we need is to be able to give the client the possibility to use the reader/writer connected to his PC.
If needed, I would have total access to the client machines (if I need to give the application any kind of special permissions).
Thanks in advance for any clue you could give me!
You can't do anything in native Air, which would be the runtime that would expose such an API. You can do a native system app (Windows or Mac) and that app leverages two processes that communicate with eachother.
The main process would spawn two processes
Air client
Smart Card Reader writer
So the main app would work as a HUB between the two.
Maybe it's worth to look at a FlashPlayer app that runs in the browser and communicates with a Java Applet via ExternalInterface.
In my knowledge, most of android tutorials and examples out there rely on use of GCM for sending data from server to android device; and use php scripts along with post/get methods to send data from device to server.
A friend of mine(someone who doesn't have any knowledge of android programming) simply asked me, why can't we use Socket class in java? In traditional java programming, you use sockets (IP adress + port no.) to achieve functionality similar to GCM (single server multiple clients - using proper techniques you can ensure messages are not lost, just like gcm).
Can this traditional socket approach be implemented in android as well? If so, what are the pros and cons of GCM and Sockets? In which situations would the use of sockets be appropriate?
Whatsapp and lot of other apps, to my knowledge, use GCM. Are there apps which use sockets?
P.S: I'm just a C.S. student; apologies if I've got my concepts wrong somewhere
GCM uses sockets too. However, they are managed by the system and thus can do things a regular app cannot do. Generally, for any type of 'push' notifications, the system needs to have a long-lived socket, and a 'notification' is just some data received on that socket. All of this is not too hard to implement on an always connected machine, such as a desktop or a server, but there are additional challenges on mobile. For example, switching networks (3G<->WiFi), going out of range, maintaining a connection without keeping the device awake all the time (and killing the battery in the process). So yes, you could implement something similar using a service , sockets and your own server, but it's not trivial on mobile.
Check out http://mqtt.org/ for an open-source implementation.
I have a flash app which will send/receive a constant stream of data.
the flash app should open a connection to the Java server, keep it open, and attempt to reconnect on socket failure.
Are there any good APIs that offer this functionality? Smartfox Server is one option, but if I had my way I'd embed an API in my app rather than contort my app to run under Smartfox.
Ideally it would offer an API on the flash end, another on the Java end, and efficiently (java nio preferably) handle the network component in between. I would just define handlers on both the client & server.
You could use BlazeDS. It's an open source RTMP server from Adobe written in Java. You don't need any special library on the client side as RTMP is native in Flash.
There are many examples on the web: here , here.