I am trying to use ZeroMQ to connect to a historical data server written in Python while I connect to Interactive Brokers' Trader Workstation (TWS) using C++ through UNIX socket in Linux. But I can't seem to get both to work at the same time. I tried to connect to the Python server using ZeroMQ first, and then to TWS once the connection is established. But after I connect to TWS, I can't seem to interact with my original ZeroMQ connection in any way. The connection with TWS would always lose whenever I provide the ZeroMQ socket to call zmq::poll. But if I don't include the ZeroMQ socket, zmq::poll works just fine with the file descriptor from the connection to TWS. I am not too experienced with either UNIX sockets or ZeroMQ, but is it true that I can't use ZeroMQ and sockets API in the same thread? I thought it would be simple to add ZeroMQ to the original Interactive Brokers socket client, but it is more complicated than I expected. Any suggestions would be greatly appreciated.
I am trying to write a distributed server system (consisting of server 1="main", and server 2="replacement" for now). Don't mind some dirty methods, it's just to achieve a basic function a distributed server would achive.
Currently I have both servers running via SO_REUSEADDR and a TCP Socket (maybe UDP will solve my problem, but I wanna try it either way with TCP first) on the same machine.
Main server sends establishes a connection with the Replacement server and clients connecting to it.
Now what I want to achieve: The main server should send the socket of the connecting clients to the replacement server, so in case the main server can't work anymore (timeout or what ever) the replacement server can work with the clients and send/recv with them.
The socket I send from main to the replacement server is the one I get with ClientSocket = ::accept(ListenSocket, NULL, NULL); where ClientSocket is a SOCKET (UINT_PTR).
The replacement server can't send/recv to the clients even though the main server gets terminated midway.
Is that because each server, even though they run on the same port, need to be connected via a ::connect from the clients?
EDIT: If my theory is true, this should be solved by using UDP instead of TCP as well, no?
EDIT2: With distributed server I mean a server which in case of a failure will be replaced by another without the clients task getting interrupted.
EDIT3: If there is a better and more simple way to do this, I'd like to know about that as well. I'm not too fond of sockets and server communication as of now that's how I came up with my idea to solve it.
You cannot send a socket between machines. A socket is an OS concept. It represents (in this case) a connection between the server and a client. This connection cannot be resumed on a different machine that has a different IP address because a TCP connection is defined to be established between a pair of addresses and a pair of ports.
The UINT_PTR on one machine means nothing to another machine. It is an opaque value. It is an OS handle.
UDP does not solve the problem since the client needs to notice that the IP address is is communicating with has changed.
Even if you manage that you have the problem that a server failure kills all data on that server. The other server cannot resume with the exact same data. This is a basic problem of distributed computing. You cannot keep the state of all three machines completely in sync.
Make the clients tolerate interruptions by retrying. Make the servers stateless and put all data into a database.
This is a very hard problem to solve. Seek off-the-shelve solutions.
I'm able to access a telnet server via PuTTY which opens a terminal and allows me to send commands to retrieve data/logs and start/stop processes. I'd like to begin some research into how to access this server via C++ in order to automate the connection and the commands for testing. Basically I need a telnet client that can connect and authenticate itself, and write and read to/from the server as if I'm typing in a terminal. Where should I start my research? I've tried a couple examples including:
http://lists.boost.org/boost-users/att-40895/telnet.cpp
When I compile and run
./telnet 192.168.1.26 23
Nothing happens, but when I connect to the server with PuTTY I get:
QNX Neutrino (localhost) (ttyp0)
login: root
password:
#
Any help would be greatly appreciated.
Notes:
- I am using a Mac running OS X Version 10.7.3 with i686-apple-darwin11-llvm-gcc-4.2
- I am allowed to be doing this.
- I use PuTTY on my Windows 7 machine, the connection is ethernet to USB ethernet adapter, and the settings for the Local Area Connection Properties > TCP/IPv4 Properties: are a specific IP address, Subnet Mask, and Default gateway, which might be useful information.
Thanks
Learn how to program TCP/IP sockets. You can use the boost libraries, or straight C style BSD sockets. Some info here, here and here. If paper is your thing, you could get Volume 1 of Unix Network Programming. That book has such a good reputation that you get votes just for mentioning it on StackOverflow.
What you want to do closely matches the functionality of telnet and expect. You can have a look at there sources here and here for ideas.
Consider just using expect to solve your problem :)
You should start by learning the network API for the system you're trying to connect from. Telnet is just sending straight up text through a tcp/ip socket.
TCP standard has "simultaneous open" feature.
The implication of the feature, client trying to connect to local port, when the port is from ephemeral range, can occasionally connect to itself (see here).
So client think it's connected to server, while it actually connected to itself. From other side, server can not open its server port, since it's occupied/stolen by client.
I'm using RHEL 5.3 and my clients constantly tries to connect to local server.
Eventually client connects to itself.
I want to prevent the situation. I see two possible solutions to the problem:
Don't use ephemeral ports for server ports.
Agree ephemeral port range and configure it on your machines (see ephemeral range)
Check connect() as somebody propose here.
What do you thinks?
How do you handle the issue?
P.S. 1
Except of the solution, which I obviously looking for,
I'd like you to share your real life experience with the problem.
When I found the cause of the problem, I was "astonished" on my work place people are not familiar with it. Polling server by connecting it periodically is IMHO common practice,
so how it's that the problem is not commonly known.
When I stumbled into this I was flabbergasted. I could figure out that the outgoing
port number accidentally matches the incoming port number, but not why the TCP
handshake (SYN SYN-ACK ACK) would succeed (ask yourself: who is sending the ACK if
there is nobody doing a listen() and accept()???)
Both Linux and FreeBSD show this behavior.
Anyway, one solution is to stay out of the high range of port numbers for servers.
I noticed that Darwin side-steps this issue by not allowing the outgoing port
to be the same as the destination port. They must have been bitten by this as well...
An easy way to show this effect is as follows:
while true
do
telnet 127.0.0.1 50000
done
And wait for a minute or so and you will be chatting with yourself...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
hello?
hello?
Anyway, it makes good job interview material.
Bind the client socket to port 0 (system assigns), check the system assigned port, if it matches the local server port you already know the server is down and and can skip connect().
For server you need to bind() socket to port. Once addr:port pair had socket bound, it will no longer be used for implicit binding in connect().
No problem, no trouble.
Note that this solution is theoretical and I have not tested it on my own. I've not experienced it before (or did not realize) and hopefully I won't experience it anymore.
I'm assuming that you cannot edit neither the client source code nor the server source. Additionally I'm assuming the real problem is the server which cannot start.
Launch the server with a starter application. If the target port that the server will bind is being used by any process, create an RST (reset packet) by using raw sockets.
The post below briefly describes what an RST packet is (taken from http://forum.soft32.com/linux/killing-socket-connection-cmdline-ftopict473059.html)
You have to look at a "raw socket" packet generator.
And you have to be superuser.
You probably need a network sniffer as well.
http://en.wikipedia.org/wiki/Raw_socket
http://kerneltrap.org/node/3072 - TCP RST attacks
http://search.cpan.org/dist/Net-RawIP/lib/Net/RawIP.pm - a Perl module
http://mixter.void.ru/rawip.html - raw IP in C
In the C version, you want a TH_RST packet.
RST is designed to handle the following case.
A and B establish a connection.
B reboots, and forgets about this.
A sends a packet to B to port X from port Y.
B sends a RST packet back, saying "what are you talking about? I don't
have a connection with you. Please close this connection down."
So you have to know/fake the IP address of B, and know both ports X
and Y. One of the ports will be the well known port number. The other
you have to find out. I thnk you also need to know the sequence
number.
Typically people do this with a sniffer. You could use a switch with a
packet mirroring function, or run a sniffer on either host A or B.
As a note, Comcast did this to disable P2P traffic.
http://www.eff.org/wp/packet-forgery-isps-report-comcast-affair
In our case we don't need to use a sniffer since we know the information below:
So you have to know/fake the IP address of B, and know both ports X
and Y
X = Y and B's IP address is localhost
Tutorial on http://mixter.void.ru/rawip.html describes how to use Raw Sockets.
NOTE that any other process on the system might also steal our target port from ephemeral pool. (e.g. Mozilla Firefox) This solution will not work on this type of connections since X != Y B's IP address is not localhost but something like 192.168.1.43 on eth0. In this case you might use netstat to retrieve X, Y and B's IP address and then create a RST packet accordingly.
Hmm, that is an odd problem. If you have a client / server on the same machine and it will always be on the same machine perhaps shared memory or a Unix domain socket or some other form of IPC is a better choice.
Other options would be to run the server on a fixed port and the client on a fixed source port. Say, the server runs on 5000 and the client runs on 5001. You do have the issue of binding to either of these if something else is bound to them.
You could run the server on an even port number and force the client to an odd port number. Pick a random number in the ephemeral range, OR it with 1, and then call bind() with that. If bind() fails with EADDRINUSE then pick a different odd port number and try again.
This option isn't actually implemented in most TCPs. Do you have an actual problem?
That's an interesting issue! If you're mostly concerned that your server is running, you could always implement a heartbeat mechanism in the server itself to report status to another process. Or you could write a script to check and see if your server process is running.
If you're concerned more about the actual connection to the server being available, I'd suggest moving your client to a different machine. This way you can verify that your server at least has some network connectivity.
In my opinion, this is a bug in the TCP spec; listening sockets shouldn't be able to send unsolicited SYNs, and receiving a SYN (rather than a SYN+ACK) after you've sent one should be illegal and result in a reset, which would quickly let the client close the unluckily-chosen local port. But nobody asked for my opinion ;)
As you say, the obvious answer is not to listen in the ephemeral port range. Another solution, if you know you'll be connecting to a local machine, is to design your protocol so that the server sends the first message, and have a short timeout on the client side for receiving that message.
The actual problem you are having seems to be that while the server is down, something else can use the ephemeral port you expect for your server as the source port for an outgoing connection. The detail of how that happens is separate to the actual problem, and it can happen in ways other than the way you describe.
The solution to that problem is to set SO_REUSEADDR on the socket. That will let you create a server on a port that has a current outgoing connection.
If you really care about that port number, you can use operating specific methods to stop it being allocated as an ephemeral port.
How do I detect if a remote client is running Remote Desktop Protocol? and it is also accepting remote desktop connections ??
Like Open an port to detect HTTP and send request, receive request headers and see in request headers information about HTTP so I will know the person is running HTTP weather if he changed the port e.g: running HTTP 6551.
Attempt and make a connection with something that is RDP-connection aware (RDP is not HTTP). Of course, failing to establish an initial handshake is not proof that a connection can not be established. It could be blocked by a firewall, listening on another port, etc.
The MS-RDPBCGR specification, page 16 talks about connecting which in turn defers to X.224, go figure.
It'd likely just be easiest to use Wireshark and observe in-the-wild behavior to develop a minimal detection case. I suspect only the very initial portion of the handshake needs to be generated/replayed in order to "decide" that it's a listening RDP server.
(Or, perhaps use an existing RDP client which has this "test connect" functionality or the ability to be scripted.)
A fast way is to pen a shell and type
telnet IPADDRESS 3389
If you get a connection, chances are good that an RDP server is on the other side. RDP can run on any port, but TCP Port 3389 is set per default.
Windows 7 requires some extra steps to enable the telnet Client.
You could do netstat -a in the command line and see if the default port for remote desktop connection is listening, ie. TCP:3389 but thats only if the client hasn't changed the ports for MSTSC