Can I receive data from network by some processes simultaneously?
For instance, I have two computes in the LAN. One computer send udp packet to other computer on port 5200. In computer number two I want to receive this packet by two processes. Can I create two sockets on same ip and port?
I forget to say that Process A I can't modify. In other words, I want to create application that receive same data as Process A. (Proccess A and Proccess B locate on the computer number two that receive data)
Yes! You can. Open the socket and set setsockopt with REUSE_PORT and REUSE_ADDRESS.
How about you create process A to act as middleware between the two processes B and C. And then add extra data to the packets sent to process A which will be used to determine the final destination of the data - process B or process C.
EDIT:
To answer your question exactly "no", for TCP/IP
"You can only have one application listening on a single port at one time."
Actually you question has been asked by someone else before, and I have only just cited the answer. The full answer can be found -> here.
Related
A server listening on a UDP port, many clients can connect to it, there are many groups of clients connected to it. In a group one client is sending message and the server needs to route the message to the rest in the group. Like this many groups could be running simultaneously. How can we test what is the maximum number of connections the server can handle without inducing a visible lag in the response time ?
Firstly, let me desrcibe your network topology again. There is a server and many clients, clients are divided into several groups. A client sends a message to the server, and then the server sends something to the other clients in that group.
If the topology is like what I describe above, is the connections limitation you want to reach about how many clients the server can send to at the same time? Or do you want to know how many clients can send to server at the same time?
The way to test these two different circumstances may be using multi-thread or go routine if you can write by go. But they need to set different judge to give out the limitation.
I have Created A UDP Server-Client application. There is only single thread at Server's side which continuously executes recvfrom().
If I run 3 Clients Simultaneously from 3 different machines, and send some data, the Server is able to read the data from each of the client.
But how can I test the reliability of this application?
How would I know how many Maximum number of Clients can this Server handle at a time?
Also what is the maximum Payload?
But how can I test the reliability of this application?
Run as many clients as you can. The more clients you can run and send data, the better. Try to run many clients of different machines, and on each machine try to run as many clients as you can, and keep sending data automatically.
Make the clients send data in a loop, without waiting for input, and put a delay between each call to send. A few seconds of delay is fine, then you can lower the delay later and see how your server is handling it.
How would I know how many Maximum number of Clients can this Server handle at a time?
You can't. You are using a UDP server, and UDP is connectionless. Clients do not need to connect to the server to send data, they just send it. Usually it is limited by available resources (memory, etc.) on your server.
Also what is the maximum Payload?
The maximum payload of what? A UDP message? You can read more about the UDP packet structure.
Is it doable to listen a device with 2 different filters and capture packets? For example i start listening a device with a filter and dumping the packets to a pcap file, after 15min can i start another listen on the same device with different filter and dump the packets to another pcap file without stopping the old one?
Does pcap_open or pcap_next_ex block the incoming packets? What i mean if a packet arrives while listening from two different threads one of them will get the packet and control it for filter can the other thread access the packet?
I hope im clear sorry for bad english.
can i start another listen on the same device with different filter and dump the packets to another pcap > file without stopping the old one?
Yes. Albeit, you'd better start that listener in a different thread/process to process it.
Does pcap_open or pcap_next_ex block the incoming packets?
It does not. It drops the packets to your pcap listener if one part (you or the OS) can't keep up with the incoming packets.
pcap will also duplicate the packets(speaking at least of the *nix pcap, assuming winpcap works the same) so if you have several pcap listners, filtering for the same packets , they will all get a copy.
For each open device handle you get, you have a seperate filter, and packet buffer.
say handle 'A' and handle 'B'
now lets say both handles are on the same network device.
Now lets say that the network device gets 4 packets.
each packet gets to the hardware driver, then to winpcap.
at that point winpcap applys each handles filter one at a time.
if a match is made, the packet will be copied to that handles packet buffer.
after all handles have been processed, the packet is handed off to the OS.
Does pcap_open or pcap_next_ex block the incoming packets? No.
The fact is that the operating system, will most likely see the packet before your application will process it.
I may be wrong but I don't think winpcap has any standard method for blocking a packet.
I have situation where I have to handle multiple live UDP streams in the server.
I have two options (as I think)
Single Socket :
1) Listen at single port on the server and receive the data from all clients on the same port and create threads for each client to process the data till the client stop sending.
Here only one port is used to receive the data and number of threads used to process the data.
Multiple Sockets :
2) Client will request open port from the server to send the data and the application will send the open port to the client and opens a new thread listening at the port to receive and process the data.Here for each client will have unique port to send the data.
I already implemented a way to know which packet is coming from which client in UDP.
I have 1000+ clients and 60KB data per second I am receiving.
Is there any performance issues using the above methods
or Is here any efficient way to handle this type of task in C ?
Thanks,
Raghu
With that many clients, having one thread per client is very inefficient since lots and lots of context switches must be performed.
Also, the number of ports you can open per IP is limited (port is a 16 bit number).
Therefore "Single Socket" will be far more efficient. But you can also use "Multipe Sokets" with just a single thread using the asynchronous API. If you can identify the client using the package's payload, then there is no need to have a port per client.
If I understand the parallel port right, sending data from (D0 to D7) simultaneous, but that it can control the sticks individually?
example:
D0 = Input
D1 = Input
D2 = Output
...
...
...
D7 = Input
would it work?
what I want to do is to both send and receive data simultaneously.
Data wires (D0-D7) are being read or set simultaneously. For various tecniques for bidirectional I/O read the attached articles:
Standard parallel port: http://www.beyondlogic.org/spp/parallel.htm
EPP: http://www.beyondlogic.org/epp/epp.htm
ECP: http://www.beyondlogic.org/ecp/ecp.htm
This site is a good source for programming the parallel port.
The basic idea is that you need a DLL, add-on or library that allows you to access the I/O Ports of the PC. For Windows XP on up you need a specific driver that will allow you do this as the OS doesn't offer access out of the box.
The Parallel port will generally reside at one of three address 278,378, 3BC. This port. have the bytes you are reading or writing.
The (base)+1 port allows access to the status bytes. IE. 279,379, 3BD
The (base)+2 port allows access to the control bytes. IE. 27A,37A,3BE
The parallel port documentation will tell not only how to implement the common modes (like bi-directional) but how to control the port at the byte level to implement your own custom.
Back in the day there was only the standard mode available. You pump out your bytes at the (base) port. Some application, like mine, manipulated individual bits of that ports as form of cheap Digital I/O Controller. We did use the status and control bytes as additional inputs and outputs. There were commands you can send to the Parallel Port chip configure the modes precisely.
Today there are are hundreds of sites with example of using the Parallel Port to solve all kinds of problems. I would be surprised that one of doesn't have something you can use for you specific application.
Again the book I recommend starting with is Parallel Port complete. It tells just about everything you need to start with. If your application is too esoteric for that book it will give a springboard from which you can find the exact setup you need.
Of course by sending a number that has just the required bit set (2n) you'd get the expected result.
I'm not sure about bidirectional access though. I guess it's achieved by using control pins along with the data pins but that's just a guess.
Parallel ports doing EPP or ECP only allow D0-D7 to be all input or all output. Trying to do otherwise may fry your hardware.
See http://www.nor-tech.com/solutions/dox/ieee1284_parallel_ports.pdf, page 6.
However, parallel ports have several control lines that may be useful if you only need a small amount of input/output in the "other" direction.
I believe its bit 5 in the port's control register (base address + 2) that switches direction. (no hardware line attached)