I have one Batch job on one server which is intern calling the service on the other server.
The issue is-(we suspect)the batch job is unable to call the service,but we are not very sure.
How to ensure that service is not getting called from the network point of view.
we checked telnet between the two servers which is fine.
Is this the only way to troubleshoot?
note: we can not do the code level changes now.
You could make use of tools like wireshark or
tcpdump to capture the network traffic and see that your script is indeed sending o/g requests.
Related
The virtual machine which run Locust has multiple network cards
Is there any way to set source request IP of Locust?
https://docs.locust.io/en/stable/configuration.html#command-line-options
It should be possible by monkey patching socket.create_connection() using the solution described here, as Locust’s HttpUser uses requests.
Requests, bind to an ip
My original answer was deleted by a mod for some unknown reason. Lets hope it doesnt happen again...
I set variables host and port instead of setting the 'address' variable tuple in socket.py. I was unable to get 'address' as a tuple to work. I do not believe this is the issue, but I thought I should state this up front.
FYI, my goal is an integrations project, and I believe I isolated socket.py as the problematic code. socket.py is not creating a listener on the remote server. I run the python script on my client, and my server address is 192.168.1.130 port 7879.
I think socket.py is the problem, because I do not receive the expected print statements back through the console that socket.py is attempting to create a socket. In addition, I can RDC to the server, disable ufw (yes I know this is a bad idea), create a tcp listener, push data through the client socket to the server socket, and verify this with netcat.
Am I mistaken that I should be able to parameterize socket.py with nothing more than a host and port and be able to create a socket connection? I am happy to provide more detail from logs, but I thought I should start with a very high level overview.
Answer: More investigation needed. I think socket.py does not create the remote connection with socket(),bind(),listen() statements; instead simply looks for a listener on the remote server with a connect() statement. This is entirely my misunderstanding given I did not dive into the details of the socket.py code. I figured this out because the service running on the remote server creates the listener, but the service itself on the remote server is what is not properly starting.
I am using a perl script to log onto a remote router running JUNOS and get few information through the NETCONF port.
I am using the following library in order to do this
Net::Netconf::Manager
Net::Netconf::Device
Net::Netconf::Access
The script runs on the routers present on the same network but is failing to log into the routers that are on different networks, where as i am able to log onto the routers manually through Netconf over ssh.
The arguments I am parsing looks fine. Could any one help me resolve why this is happening.
If I need to do any checks in configuration (configuration looks fine to me) prior to running the script.
For example http://www.utorrent.com/testport?port=12345
How does this work? Can the server side script attempt to open a socket?
There are many ways of accomplishing this through server-side scripting. As #Oded mentioned, most server-side handlers are capable of initiating socket connections on arbitrary ports, and most of those even have dedicated port-scanning packages/libraries (PHP has one in the PEAR repository, Python's 'socket' module makes this type of tasks a breeze, etc...)
Keep in mind that on shared host platforms, socket connections are typically disabled for security purposes.
Another way that is also very easy to accomplish is to use a command-line port-scanner such as nmap from your server-side script. i.e in PHP, you would do echo ``nmap -p $port $ip\
The server side script will try to open a connection on the specified port to the originating IP.
If there is no response (the attempt will timeout), this would be an indication that the port is not open.
The server can try, as #Oded said. But that doesn't ensure the receiver will respond.
Typically, something like this happens:
The URL request contains instructions about which port to access. The headers that your browser sends include information about where the request is originating from.
Before responding to the request, the server tries to open a port and checks if this is successful. It waits a while before timing out.
The webpage is rendered dynamically based on the results of this test.
The response is returned to you containing the results.
Sometimes steps (2) and (3) will be replaced with an AJAX callback, which allows the response to return sooner.
What is the best way to access a running mono application via the command line (Linux/Unix)?
Example: a mono server application is running and I want to send commands to it using the command line in the lightest/fastest way possible, causing the server to send back a response (e.g. to stdout).
I would say make a small, simple controller program that takes in your required command line arguments and uses remoting to send the messages to the running daemon.
This would be similar to the tray icon controller program talking to the background service that is prevalent in most Windows service patterns.
Mono's gsharp tool is a graphical REPL that lets you Attach to Process.
#Rich B: This is definately a suitable solution, which I already had implemented - however on the server I have to use, the remoting approach takes around 350ms for a single request.
I've measured the time on the server side of the request handling - the request is handled in less than 10ms, so it has to be the starting of the client program and the tcp connection, that takes up the time.
Hence the hope that I can find another way to post the requests to the server application.
You can use the system.net.sockets abstractions to create a service on a TCP port, and then telnet to that port.
Check the library status page; Mono's coverage here is a bit patchy.