fast return of data to the server
-
с++ compiler
Hello colleagues.
There is one task, and I think how to implement it more correctly and faster.
In general terms, transfer many different binary data to 1 server.
There is an iocp asynchronous server that receives data from clients.
Then this processed data is converted and added to the queue packets.
There can be many such packets per second (300 - 1000).
Asynchronous processing parses this queue, and the data in each packet in the queue
should be given over TCP / IP to another server. I do not want to create an additional stream for the client per packet from queue parsing. Is there any quick fix?packets of
queue :1 ->to 127.0.0.1 3615
2 ->to 127.0.0.1 3615
3 ->to 127.0.0.1 3615
4 ->to 127.0.0.1 3615
5 ->to 127.0.0.1 3615
6 ->to 127.0.0.1 3615
7 ->to 127.0.0.1 3615
8 ->to 127.0.0.1 3615
9 ->to 127.0.0.1 3615
..
..Thank you.
-
с++ compiler
Hello colleagues.
There is one task, and I think how to implement it more correctly and faster.
In general terms, transfer many different binary data to 1 server.
There is an iocp asynchronous server that receives data from clients.
Then this processed data is converted and added to the queue packets.
There can be many such packets per second (300 - 1000).
Asynchronous processing parses this queue, and the data in each packet in the queue
should be given over TCP / IP to another server. I do not want to create an additional stream for the client per packet from queue parsing. Is there any quick fix?packets of
queue :1 ->to 127.0.0.1 3615
2 ->to 127.0.0.1 3615
3 ->to 127.0.0.1 3615
4 ->to 127.0.0.1 3615
5 ->to 127.0.0.1 3615
6 ->to 127.0.0.1 3615
7 ->to 127.0.0.1 3615
8 ->to 127.0.0.1 3615
9 ->to 127.0.0.1 3615
..
..Thank you.
-
I wanted to clarify.
When the packet went to the server, we expect a response from it.
Once the correct answer is received, the packet is removed from the queue.
The faster the queue is empty, the faster the other server will receive the packets.I'm confused: 1. TCP/IP already takes care of packet delivery; it makes sure it arrives, and if it doesn't, it gets resent. Why implement another queue on top of that? That just creates more traffic, and you made a point you want to avoid that. 2. You said something about asynchronous processing, but if you implement a queue as you said, it enforces synchronization! So what do you want? Synchronized or not? That said, I have no experience in programming this kind of stuff, I only know the theory. But maybe there's something to the many things people say about theory and practice http://wiki.c2.com/?QuotesOnTheoryVsPractice[^] ;)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)