I am using UDP network protocol to send message from various clients to a root server.
The message from client to server may not be sent directly and may be sent via other clients.
I want to know the clients via which the message is sent by looking at the message received at the root server. How to do this?
UDP does not include this information. You'll need to include something in your protocol if you want to keep track of servers through which the message has passed.
The traceroute program uses a trick to get bounced packets by setting the TTL to an increasing number. It starts with a TTL of 1 so that the first bounce comes from the closest server to the source. It then tries a TTL of 2 to get a bounce from the second server on the path, and so on.
traceroute is client-side and heuristic, i.e. works only for stable connections. Since you are essentially constructing an overlay network, the only ways to get information about the route is reconstructing the routing according to your routing algorithm (hard, and probably infeasible in a distributed network) or having each relay add a note (typically consisting of the relay's name, and the previous IP address) to the message.
Related
I'm using a real machine (hp procurve) for my project, I need to send message of other protocol format, OSPF for instance, instead of flows, from controller side to OpenFlow switch through socket(by specifying ip address and port of the OF switch).
But everytime I try to do this, I get "Connection refused" error message, I guess that it might be that the port on OpenFlow switch I'm sending the message to is not listening, so I think I might need to use the same port for the sending which OpenFlow switch uses to talk to the controller, like the port 51067 in the log info :
Switch:192.168.1.11:51067 is connected to the Controller
My question is, how do I retrieve the port information on the controller side, since it is changing every time I restart it? I couldn't find this information.
Or am I going the wrong direction that I need to go another way around instead of sending the message using socket?
Thanks a lot in advance, any suggestions will be appreciated.
jonesir
I think you are misunderstanding the nature of networking ports, protocol numbers, and protocols such as OSPF. Let me clear those up:
Port numbers: Usually, there is exactly one application listening on a single port: The operating system/networking stack checks each packet of certain types (e.g. TCP or UDP) for the port number and then passes the packet to the application that registered itself for that specific port. If the application cannot handle the received packet then usually it will just ignore it or log an error.
Aside: It is possible for two applications to communicate on the same port only if you put some sort of multiplexing application before both (usually a reverse proxy, possibly a TCPMUX application). This multiplexing application would take incoming packets, determine what type of packet it is and then pass it to the correct application.
Protocol numbers: The protocol number is a field inside an IP packet that tells the networking stack what type of data is contained inside. For example, TCP is protocol 6, ICMP is 1, and OSPF is 89.
OF switches: Now, logically an OF switch consists of two components: 1) the switching fabric (which includes the physical ports and OF flow tables), and 2) a separate physical port to for out-of-band control, with several applications running behind it. One of these applications is the OpenFlow application, which in your case happens to listen on port 51067. But in real switches, other applications might also be running on different ports, e.g. a web interface running on port 80 for maintenance etc.
OSPF: If you now wanted to talk to the application serving the web interface, you'd send a TCP packet with destination port 80 from your controller to the switch. Similarly, if you'd like to install a new flow, you'd send an TCP packet with port 51067 in your case. OSPF is quite different, as it directly uses IP packets and does not use port numbers. To process an OSPF packet, an application needs to use a raw socket to process the incoming IP packets that have protocol number 89, and skip all others. See also the raw manpage here. This will already be built into your OF switch.
Thus, if you want to send an OSPF packet to the OF switch (and your OF switch supports OSPF on the separate physical port!), you'd just send an OSPF IP packet to the switch's IP address (192.168.1.11), no port needed!
Note that the separate physical port might not support all of the features of the other ports on the OF switch, as they are not intended for the same uses.
I'm building a chat server with .NET. I have tried opening about 2000 client connections and my Linksys WRT54GL router (with tomato firmware) drops dead each time. The same thing happens when I have several connections open on my Azureus bit-torrent client.
I have three questions:
Is there a limit on the number of open sockets I can have in Windows Server 2003?
Is the Linksys router the problem? If so is there better hardware recommended?
Is there a way to possibly share sockets so that I can handle more open client connections with fewer resources?
AS I've mentioned before, Raymond Chen has good advice on this sort of question: If you have to ask about OS limits, you're probably doing something wrong. The IP protocol only allows for a maximum of 65535 ports and many of these are reserved and not available for general use. I would suggest that your messaging protocols need to be thought out in more detail so that OS limits are not an issue. I'm sure there are many good resources describing such systems, and there are certainly people here that would have good ideas about it.
EDIT: I'm going to put some thoughts about implementing a scalable chat server.
First off, designate a single port on the server for clients to communicate through. Whenever a client needs to update the chat state (a new user message for example) do the following:
create message packet
open port to server
send packet
close port
The server then does the following:
connection request received
get packet
close connection
process packet
for each client that requires updating
open connection to clients
send update packet
close connection
When a new chat session is started, the client starting the session sends a 'new session' message to the server with the clients user details and IP address for responses. The server creates a new chat session and responds with the session ID. The client then sends packets containing the messages the user types, the server processes them and forwards the message to other clients in the same session. When a client leaves the chat, it sends a 'end session' message to the server. The server removes the client from the session and destroys the session when there are no more clients in the session.
Hope that gets you thinking.
i have found some answers to this that i feel i should share:
Windows 2003 server has a limit on the number of ports that may be used. but this is configurable via a registry tweak to change the MaxUSerPort setting from 5000 to say, 64k( max).
Exploring further, i realize that the 64k port restriction is actually per IP address, hence a single server can easily attain much more ports, and hence TCP connections by either installing multiple network cards, or binding more than one IP address to a network card. that way, you can scale your system to handle n x 64k ports.
Had for days a problem with the available sockets on my Window 7 machine. After reading some articles about socket leaks in Win 7, I applied a Windows patch - nothing changed.
Below there is an article describing windows connection problems in great detail:
http://technet.microsoft.com/en-us/magazine/2007.12.network.aspx
For me it worked the following:
Open Regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters: Create TcpNumConnections, REG_DWORD, decimal value 500 (this can be set according to your needs); EnableConnectionRateLimiting, REG_DWORD, value 0;
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip: Create MaxUserPort, REG_DWORD, decimal value 65534
Restart Windows
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
Is it possible to modify users' HTTP request to
www.example.com/options
instead of
www.example.com/options_and_params
My scenario is that about 30000 users connect to my company's network backbone and I want to add one or more server (with the code I'm current working on) between the backbone switches and Radware LoadProof to achieve this work.
After googling all the night, I have no lead but some more questions:
I don't need to intercept every packet through the network. With some helps like iptables, I can filter out the package I want. I have done it before using iptables. However, packet is not equal to HTTP stream. Do I need to do HTTP re-construct?
If I successfully find a way to modify HTTP request URL content, I still should put it back to network stream. As I know TCP packets have a checksum and after I modify the content it must be wrong. How do I calculate a new checksum and put the packet back to network?
It's my first time to do network programming or packet processing develop. Any suggestion is appreciate.
This depends on whether you are doing HTTP/1.0 or HTTP/1.1 and whether its an initial request you need to modify or all requests in a single HTTP 1.1 session.
If you have the packet and can modify it before it is sent on and you are trying to modify just the request then given the length of a typical packet and the location of the URL in the HTTP request stream (very near the beginning) and the fact that it will be the first thing sent in the TCP stream I think you can fairly safely assume that it will be present in the first N bytes of the first packet sent and therefore won't be split over multiple packets.
However, if this is an HTTP/1.1 stream then multiple requests will be being sent via the same TCP connection in which case in future requests the URL may well be split over two TCP packets.
If you can maybe force HTTP/1.0 or possibly if you modify the initial or all requests to be HTTP/1.0 then you can be pretty sure that the first packet will correspond to the first packet of the TCP stream and that you are very unlikely to see the URL split over multiple packets, meaning no reconstruction and the ability to just do a replace.
However this will come at a cost of new TCP connections which is pretty inefficient.
If you don't and you leave it as HTTP/1.1 then the URL could be at any random point in any future request and therefore split over multiple TCP packets (two realistically given the size of the URL).
If I got your question right, then this could be probably done with some fast reverse-proxy like nginx.
I'm want to design a ruby / rails solution to send out to several listening sockets on a local lan at the exact same time. I want the receiving servers to receive the message at exact same time / or millisecond second level.
What is the best strategy that I can use that will effectively allow the receiving socket to receive it at the exact same time. Naturally my requirements are extremely time sensitive.
I'm basing some of my research / design on the two following articles:
http://onestepback.org/index.cgi/Tech/Ruby/MulticastingInRuby.red
http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm
Now currently I'm working on a TCP solution and not UDP because of it's guaranteed delivery. Also, was going to stand up ready connected connections to all outbound ports. Then iterate over each connection and send the minimal packet of data.
Recently, I'm looking at multicasting now and possibly reverting back to a UDP approach with a return a passive response, but ensure the message was sent back either via UDP / TCP.
Note - The new guy syndrome here with sockets.
Is it better to just use UDP and send a broad packet spam to the entire subnet without guaranteed immediate delivery?
Is this really a time sensitive component? If it's truly down to the microsecond level then you may want to ensure its implemented close to native functions on the hardware. That being said a TCP ACK should be faster than a UDP send and software response.