I am using simple UDP connection.
I would like to know if by default the connection has "Carriage return" enabled or disabled, and how could I set that property?
thanks,
ray.
Eh, that's not entirely accurate. UDP isn't differentiated by virtue of sending text vs. binary. All network protocols ultimately send data as bit streams (binary). What typically differentiates it is that unlike TCP, there is no back and forth to establish sequence numbers for tracking packets, and no ACK flag to signal that a packet was received. UDP will send packets with no regard to whether or not they get to the destination.
Edit: Ray maybe you should provide a little more detail about what you're trying to do. Carriage Return is an ascii character just like any other. It has a numerical representation and occupies a byte of space just like the other ascii characters. So asking if it's "enabled" for UDP transmission isn't really a valid question. Any series of bits can be sent via UDP, or TCP, or any other protocol - which means UDP doesn't even understand what ASCII is, or the letter "b", or a carriage return. It's all just a bunch of 1's and 0's, and UDP is aware of IP addresses and Port numbers - just enough to send your bits of data somewhere. What your application does with those bits is the question.
UDP traffic is session/connection less. So you can't have a "connection" on UDP.
UDP is used to pass binary data rather than text and there is no way to disable carriage return or any other character.
UDP broadcasts binary data - if you encode \r and/or \n to bytes and add it to the message, it will be sent. No filtering, no conversion on this protocol layer.
Related
All,
Not sure whether to create some Java code or use an 'off-the-shelf' product to produce a listener / router / redirector, one which will listen to a single incoming IP stream and then 'redirect' packets based on a fixed position string variable to an appropriate TCP server.
i.e. If the incoming packet has variable = 1 redirect to a TCP server at 192.168.150.211, if a 2 then redirect to TCP server at 192.168.150.212.
Ideally the code / product should also be able to pre-launch multiple TCP servers (either at one IP address and different IP ports or at different IP addresses) on the same machine prior to the listener / router starting.
Was thinking of using an OPC server but these seem too complex / costly for a single, relatively slow, incoming stream.
Thoughts appreciated.
This depends on the depth of analyzing. If you would like to analyze each packet at TCP-level then low-level language like C will be the best choice: just listen everything that comes to eth0 (or whatever interface), search for specific string (BTW "string" definition is too wide. The times when a string could be considered as ready-to-process data are in the '80s. Nowadays string is a piece of rubbish until you know what encoding is, how lines are terminated, etc).
As already mentioned by #f1sh you can redirect traffic using Java. But Java operates with streams, it knowns nothing about network packets. Also, in Java you can listen only on certain port(s) - there is no way to filter on the whole network interface (but JNI can be real saver).
If you would like to get PoC without huge amount of coding lets consider Socat. Socat can not only transmit data from one socket to another. It can also write data to files. So you can combine Socat (don't forget about fork option), tail, grep and a bit of Bash stuff and get simple redirection server working.
I recently bought an Arduino with an LCD screen. I want to push information from my computer to the Arduino. I came across a great article, How to make a physical Gmail notifier. From what I understand, I have to send the information using Serial and read it in the C/C++ code on the Arduino. That is fine, but I want to send different information to the device.
Say I want to have one part of the LCD-screen showing the temperature outside and another part of the screen display when the next bus is coming. Is there any way to "mark" the information I send with Serial, or does everything end up in the same "channel"?
If that is the case, is there a logical, simple way to separate this information so it does not mistake bus-information for temperature and vice versa?
You need a protocol for sending information across the serial line, so that the data can be collected the other end in a way that makes sense. A simple protocol may be:
T:16.0 09.34 // Temperature, 16.0°C measured at 09.34
B:11b 11.46 // Bus, route 11b, arrives at 11.46 at your bus-stop.
M:mats#example.com 11kb 10.23 // Mail from mats#example.com, it's 11KB and arrived at 10.23
Each line contains one type of information.
Assuming the line of communication is reliable (and as long as your wire isn't several dozen feet, it should be), you don't need more than that. If the communicatio is unreliable, you need some sort of "start" and "end" markers (or a start and a length), a checksum and some way of dealing with "it went wrong". You will also need to read with a timeout, so that when you don't get enough data, the system starts over again with the next bit of information.
Is there any way to "mark" the information I send with Serial
Definitely. YOU decide how the information is sent if you have control over the information passing over the serial port on your computer.
or does everything end up in the same "channel"?
Well, the serial port is a kind of a channel I guess, since all information you wish to send to the Arduino goes over the port.
is there a logical, simple way to separate this information so it does not mistake bus-information for temperature and vice versa.
Yes. Say you want to send temperature data. Create a byte array for example in this manner: {T23.4} = Temperature data
The bracket '{' signals to the receiving code in the arduino that information is coming down the line with some data. The letter T indicates temperature. Everything after the letter 'T' up to the '}' is data. (23.4)
Bus information could be {Bxxx} where xxx is the data.
when i use JPCap to forge ARP Request , i notice that jpcap is adding a trailer of 18 byte zeros to the tail of the ARP also i am not interested in sending this data. Is there a way to prevent this padding.
The zeros you're seeing are actually padding for the Ethernet frame. Ethernet packets have a minimum payload size of 42 bytes (the reasons have to do with the sender needing to transmit for a certain amount of time to detect collisions). As far as I know there's no way to prevent this, and doing so would be against the Ethernet specification.
Also see question at https://serverfault.com/questions/496324/arp-packet-received-larger-than-packet-sent-why
I'm trying to read serial data from my Arduino using Java. I have followed the tutorial Arduino and Java.
So far I have it working except, I'm not reading the whole of the serial data at once. For example, the Arduino should be sending 0.71, and I read in a 0 then a .71 or some other combination. Sometimes I read it in fine, but more often than not, the data is broken up.
I have a hunch that if I changed the data type of what I am sending to a byte, my program would be okay, however I need float precision in the data I am transferring. How do I fix this problem?
Serial protocols such as the one used for serial over USB are byte oriented, not packet oriented. As such, there's no guarantee that a read will return the entire 'message' sent by the other end, or just part of it, as you're observing, because there's no concept of message or packet.
Instead, you need to delimit your messages in some way - such as by appending a newline - or preprend messages with a length field, so you know how many bytes to read.
I do this by making my Arduino send 'frames', separated by a 'gap'. It is easy to configure a timeout (at least in Perl it is) for reading data from the serial port. So what I do is:
Allow data being read during the duration of the data frame plus an extra few milliseconds:
[ (number of bytes) × 10 bits × 1000 ms / (baud rate) ] + 100 milliseconds
Then the gap between two values or frames being sent, should be longer than this value.
The program easily synchronizes to the data stream, because of the strategic timout.
I also add a simple preamble in my data to check data integrity.
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...