I want to grab the PC screen. I use QPixmap::grab, and I get a QPixmap. Then I want to send this image using QUdpsocket. The image has been already converted to binary.
http://www.java2s.com/Code/Cpp/Qt/Udpserver.htm 's demo can send and receive the image, but use pixel, I wanna send all binary data each 250ms.
If you want to send the whole image in one go, you could try using QDataStream for serialization of a QByteArray.
The problem with this is that a UDP packet has a limited size, and could get fragmented if too large, and while large packets may work on your LAN, they could get fragmented over the internet. As UDP doesn't provide ordering guarantees like TCP, the fragments could come in the wrong order without the QDataStream header. This is probably why in your linked example they are only sending a single line at a time.
You may want to read a comparison of TCP and UDP and evaluate which fits your needs better.
Related
I have a
struct ip ipHeader;
that I want to attach in front of the actual data, which is
string data;
so that I can send it in one packet via the send function, which takes in a char* buffer. How would I go about trying to concatenate these? I need to attach this ipHeader because it's a custom header that's different from the UDP header that's automatically attached when sending messages.
edit* A clarification is that I need to attach this header along with the UDP header that's attached when sending. Hence, SOCK_RAW is not necessarily what I need/want.
In order to send two pieces of data as a single packet, you have two main choices:
Copy them both into a new buffer, and send that.
Use writev() (WSASend() on Windows).
The second approach is appealing because it seems to be designed for exactly what you're doing: sending two (or more) buffers at once. But in my own testing, it was not actually faster (on Linux) than the first approach.
The fastest and simplest solution is often to simply embed the header in your data from the start. So whenever you allocate a message, add space for the header at the start. You can then use "placement new" to invoke the header constructor if there is one, or simply assign its fields.
A professional videocamera is sending me packets over UDP and RTP, which contain MJPG-data in YUV422-pixelformat (RFC 2435). By using the DatagramSocket and DatagramPacket classes I am able to receive the packet. Now I am looking for an efficient way to get from:
approx 80 * RTP_socket.receive(rtpPacket) ---> 1 jpg-File on my Harddisk (with 25 fps)
Otherwise I am pretty soon loosing relatively many packets as, according to the UDP standard the packets are send continuously by the camera (Loosing a package once a while is not the worst as I don't need every frame).
Right now I am using a ByteBuffer to store the packets sequentially (with the header cut off using put (.. int offset...) until I got the final packet of one frame.
But unfortunately, it seems like I need to use the ImageIO.write function in order to get the necessary jpg-Header, correct? Because it cannot handle a ByteBuffer directly...
If I would do some after-processing of the image in another thread (not implemented yet), would a DirectByteBuffer make sense?
Hope you understood what I am asking :) . If not please don't hesitate to ask
Thanks a lot
You can port this C# Implementation which achieves over 100 FPS quite easily :)
https://net7mma.codeplex.com/SourceControl/latest#Rtp/RFC2435Frame.cs
I am the author and if you need porting help let me know!
I have built a simple project which use "Winsock" Tool.
When I receive any data I put it in a variable because i cann't put it in a textbox because
it is a file not a text.
But if i send a big file it gets me an error.
"Overflow"
Are there any way to fix this problem ?
A VB variable-length string can only in theory be 2GB in size, it's actual maximum size is depending on available virtual memory which is also limited to 2GB for the entire application. But since VB stores the string in unicode format it means that it can only contain 1GB of text.
(maximum length for string in VB6)
If this is your problem, try splitting incoming data by several strings.
Are you handling the SendComplete event properly before sending more data?
Otherwise you will get a buffer overflow from the WinSock control.
You need to split your data into smaller packets (around 2-5k each should do it) and send each packet individually, then re-construct your packets at the other end. You could add a unique character at the end of the data so that the receiving end know that all the data has been received for that transmission say Chr(0)?
This is quite a simplified solution to this problem - a better method would be to devise a simple protocol for data handshaking so you know each packet has been received.
When I inject any packet via WinPcap it will be captured in this moment.
I dont want to capture packets, witch were injected myself.
What is the easiest way?
The best way is to use PCAP_OPENFLAG_NOCAPTURE_RPCAP flag..
You could perhaps use a capture filter (pcap_setfilter()) and filter out packets by their source MAC address.
That may not be exactly what you want though, because MAC addresses can be spoofed, you might want to see outgoing packets from other sources on your machine, etc.
The only other thing I can think of would be to compute a hash value of each packet you send, and discard any captured packet with the same hash value.
There's got to be a better way…
I am using Ruby to test a C# networking application, which uses sockets. I open the connection with #socket = TCPSocket.new(IP,PORT) and it works - until the text I want to send is longer than 1024 characters. Then Ruby splits the message into 2 parts. C++ and C# send the message as one packet, so the C# application doesn't need to join the parts.
The messages never get longer than approx. 2000 chars. Is there a possibility to set the packet size for TCPSocket?
EDIT:
All of your answers are correct, but after reading a lot of ruby socket questions here on SO I found the solution:
socket.send(msg,0x4)
does not split the message. The option for direct send makes the difference.
I don't know if this works over the internet, but it works in my test lab.
Thx for the help.
TCP is a stream protocol. It does not care about application "messages". TCP can theoretically send your 1024 bytes in one packet, or in 1024 packets.
That said, keep in mind that Ethernet MTU is 1500 bytes. Factor in IP header, which is normally 20, and TCP header, which is at least 20. Then your 2000-char message will have to be sent in at least two packets. TCP also does flow control, which might be relevant to the issue. The best way to find out what's going on on the wire is to use tcpdump or wireshark.
The number of packets required to transmit your data should have very little effect on the stream in practice. What you might be encountering is a buffering problem in your implementation.
A socket should only be written to when it's in a "writeable" state, otherwise you risk overflowing the output buffer and causing the connection to be dropped by your networking stack.
As a TCP/IP socket functions as a simple stream, where data goes in, and comes out in order, the effect of packet fragmentation should be mostly irrelevant except for extremely time-sensitive applications.
Make sure you flush your output buffer when writing to the socket or you may have some data left waiting to transmit:
#socket.write(my_data)
#socket.flush