I am Unix java developer trying to help a datastage developer, so out of my aquarium.
The datastage process connects to a database hosting financial transactions on a unix server. there is a datastage process for migrating financial transactions to the ACCOUNTING system. The ETL developers for one reason or another have specified they cannot run one or more specific ETL while in-taking new financial transactions and have specified the process that inserts transactions into the DB be stopped.
me java geek thinks have some process checking a service running at port 55555 would be perfect. But we cannot find a way for datastage to create a socket connection to a port to check. I don't do datastage so I don't know how to work around it's limitations.
The ETL developer thinks a cron script running every minute that inserts an up/down status for the process into a special table would be perfect. I think it is a waste of cpu.
I cannot be the only company that cannot run an ETL when some process is running on a remote system.
How did you solve this issue? Is there a way to connect to a remote servers socket and run the service from datastage???
thanks
after a bunch of discussion.
options we found
Add a step to the start stop server scripts that writes process status to a table. pro: easy to implement. con: not turely accurate (some geek like me is likely to bypass the start/stop script and run only build/run the executable bypassing the start stop script and bypassing the step that inserts the status.) No network and InfoSec paperwork
Cron based script that updates the table with the status on a minute by minute basis. what a pain!!!! No network and InfoSec paperwork.
A script made available to the network through inet or xinet. Problem is datastage ETL developer does not know how to connect to a socket via C or java program. Creates Infosec and network paperwork issues.
New web service (there is a tomcat server serving up a number of web services) Problem is datastage ETL developer does not know how to connect to a socket via C or java program. Creates Infosec and network paperwork issues.
options 3 and 4 are accurate and realtime. options 1 and 2 opens up the possibility of inaccuracies by bypassing process, but that opens up a different can of worms.
We are probably going to implement option 1
Related
Does anyone know what the port used to run the task scheduler is in Windows?
Does the task scheduler have a port? May I know what the port is, or how to look for the port that the server using to run the task scheduler is?
I know that this is an older question, but maybe this will help. If I correctly understand what you're asking, you can use Task Scheduler itself or use schtasks.exe from the command prompt to manage tasks on a remote computer. I can't find a source, but can tell you that you will need port 135 open in order for this to work.
Windows doesn't expose task scheduler APIs over the network, so there's no port. If you wanted to control the task scheduler remotely, you would need to expose it to the network yourself, by writing a small server process to expose the scheduler API (inasmuch as it's available from the userspace - most of it is available only from the kernel space, i.e. from drivers).
Your idea isn't as outlandish as it may seem, though. There are operating systems where even the most basic subsystems communicate using messages sent over abstract communication ports. Minix 3, for example, by default runs the scheduler embedded in the kernel process. But the scheduler certainly can be run as a separate, communicating process in the user space. This user-mode implementation of process scheduling in Minix 3 does what you think of (almost): it is a process scheduler that runs as a separate process ("server"), and the rest of the system only communicates with it via messages. This message interface to the scheduler process (or any process, in fact), can be easily exposed over a network interface - this was done for Minix by adding a NET server to implement remote process communication.
It uses port 445 for Windows Server 2012 and later;
135/139 for the older ones.
See https://cyberark-customers.force.com/s/article/Required-Ports-for-Windows-Scheduled-Tasks-Windows-Server-2012
For Windows Server 2012 / 2012 R2 or any modern system, only port 445 is needed as it should support SMB over TCP. Port 139 is needed for older systems as it uses NETBIOS over TCP instead to transmit SMB communication from one system to another.
There is no port, nor a server. Task scheduler is just a way of scheduling things to run.
Its ran entirely on the local machine, with no net communication.
I use Delphi. I have a backup application which has to run constantly on my customers machines. Communicaton is done via TCP/IP Sockets & data is transferred via FTP.
My problem is that sometimes when the customer upgrades his AntiVirus or I send a upgrade the Firewall blocks my Application even though setup was done via elevated rights. How do I overcome this. I had thought running my communication portion from a Windows Service Application would solve the matter.
I'm building a software agent that run on a server, this software agent act as a server manager i.e. starting/stoping Docker container, monitoring etc.
This server will host/serve many services, these services are programs running in Docker container, 1 program/service per container.
There may be so many servers and these servers aren't necessary be a high performance server, they ranges from a small VM to high performance computer. Right now, I assume that every service uses HTTP to serve request.
The function that I want to implement in this software agent is tracking the number of clients that are currently connecting (requesting) to server for every service (e.x. server A is processing 500 requests) or specific program is ok (e.x. program A is processing 100 requests, program B is processing 200 request).
I want to know this number because I want to do workload balancing across servers that host the same service.
The following is ideas that I have.
Implementing load balancer/reverse proxy inside this agent (I would use this load balancer https://github.com/nwoodthorpe/Load-Balancer-Golang). This may be the last choice because I think it will use pretty much resources for load balancing.
Letting service programs that are running on server tell agent whenever they start and finish processing request. I simply implement UDP socket server in agent to listen for a datagram that tell unique ID of request (actually, can be anything that help me distinguish specific request that being processed) and status whether is being processed or finish processing.
So, I would like to ask for a suggestion for above approaches, which one is better or how should I implement it? Is there any better approach to do this?
I have a client program that communicates via a local Windows service to a server process. These three programs are implemented by ourselves. To analyze an error situation, I'd like to take crash-dumps of all three processes at once, so that there are no inconsistencies between them. The trigger is an exception in the client.
In the testing environment, the server runs on the same machine. In that case I can attach to the processes in question using .tlist and .attach. Once the exception is thrown, all processes get suspended and I can do a .dump on each single dump.
Is it possible to achieve the same result if the server is running on a different machine? How?
I have tried: attaching WinDbg to the serverside process, then running a remote debugging server (.server), connecting to it from a new WinDbg instance on the client. But then I can't attach to local processes, since the .tlist and .attach command operate on the server instead of the client.
I have a small portable tool which connects to around 150 servers at diverse locations to get a quick status check from them. It is important to get the status for all servers back to the user relatively quickly so the tool connects to the servers in parallel using non-blocking connect, and uses select() to determine when each socket is ready. The use of select() is fairly straightforward, and the tool is failure mature now and works well on Linux. It runs on windows xp, but connections to the vast majority of the servers out there do not complete. The tool staggers the calls to connect to avoid creating what looks like a SYN flood. It connects to one server about 100 msecs. I also have a check in place to ensure FD_SETSIZE is not violated. I have anecdotal evidence from someone else that the behaviour is better on later windows versions, but have not been able to verify.
I have used WinDump to verify that the syn packets are being sent, and I can see ack packets coming back, but select() keeps returning zero, and the code simply can't connect to most of the servers that do exist, and I can connect to just fine with the same code on Linux.
Has anyone seen and or solved any similar issues with many non-blocking connects and select on Windows XP?
After another day or so of digging I seem to have found the answer. On windows XP SP2 there is a limit of 10 concurrent connecting sockets system wide. If 10 or more half open connections exist, a System event is logged noting that the limit has been reached, and new connecting sockets are throttled silently. The System Event number is 4226.
I have fixed my code by adding version checks for Windows XP, and throttled to less than 10 connections on those systems. So far I have no reports of other versions being affected.