I am testing my application against three ConQuest DICOM servers running:
one on localhost, another one on a different computer in the local network, and still another one on a remote machine in the VPN network. The requesting application is present in both local and the VPN networks.
When I am trying to retrieve an image (via C-MOVE) from each of those three instances of ConQuest, both local servers duly respond the request and send me the image. The remote server on VPN, however, responds
"Host 'XXX' did not accept the connection"
and, after a timeout, closes.
I was unable to understand the reason, or, the difference - the corresponding settings in the configuration files on all three machines seem to be identical and correct.
I can successfully verify the VPN ConQuest server. I can also send images to it. But the C-MOVE retrieve does not work.
This is certainly not a firewall problem (I switched out firewall on all computers, and it did not help).
Can the problem have to do with the form of the host name? Do I need to indicate which network I mean, apart from the IP address?
Thanks A_J and everybody involved. After a while, we gathered enough experience with ConQuest and also with a couple of other PACS in real hospitals. There are principally three things to check:
The network parameters (AET, IP, port) of the PACS must be correctly registered with your application (all three you shall learn from the network admin);
The PACS must know the same three parameters of your system in its configuration (its physical implementation depending on the system). The port is the number of port on which your C-MOVE listener runs, the IP you can find with ipconfig (ifconfig), and the AET is that you chose. These data you shall tell the network administrator, so that (s)he registers them with the PACS;
Configure a firewall inbound rule on the machine where your application runs to allow connection on the port number of your C-MOVE listener.
To our experience, this is all what one needs for all practical purposes.
Related
I know there needs to be a STUN/ICE/TURN server to find the IP addresses of the peers involved in a WebRTC communication. However, even after IPs are found, how do the peers actually talk to each other independently without having any ports opened?
If you build a website, you usually have to open the ports on your server to have others access your site. What's the magic that is happening in WebRTC that I'm not understanding?
There are several strategies to do this: one possibility is for the client to explicitly open a port via UPnP. I'm not sure if any current WebRTC client does so, but in general networking this is a possibility.
Failing that, the STUN server kicks in. There are several hole punching techniques it can try; read the aforelinked article for the gory details. In short though, a firewall will usually open a port for outgoing traffic (because it needs to receive responses), so by establishing an outgoing connection to a known target and then making note of the port that was opened it is possible to open a port.
Failing even that, a TURN server is necessary. This server is publicly accessible from both peers, even if both peers cannot see each other. The TURN server then will act as a relay between the two. This somewhat negates the point of a P2P protocol, but is necessary in a certain percentage of situations (estimates range around 10%-20%).
The original Question is "what/who creates the sockets?"
The browsers creates the socket and bind them to a local port for you
during the "ICE gathering".
Wether you use any stun/turn server or
not, each candidate generated during the ice gathering has a
corresponding port open.
Those ports are usually open only for 30 mn
after which they are revoked to avoid an attack by someone using old
and/or spoof candidates. These 30mns are not specified in any
specification and are an arbitrary choice by the browser vendor. -
The next question is "how does the remote peer know about which ports are open".
through the ICE mechanism, which for each media will generate potential candidates and send them to the remote peer through your preferred signaling channel.
ICE candidates (which are one line of SDP, really) have a "type". if this type is HOST, then your candidate is a local candidate generated without the use of any stun or turn server. is the type is SRFLX, then you have used a STUN server to add the mapping between your local IP:port and your public IP:port. if your type is RELAY, same thing with a TURN server.
of course, using the local IP:port HOST candidate will fail unless the remote peer is on the same local network.
From the browser and local system point of view, the socket is open on the local IP:PORT anyway. Hence, opening the sockets and finding out on which port a remote peer should connect to connect to the socket are separate problems handled separately.
The Final question is: "can it really work without a STUN server"
Most probably no, unless you are on the same sub network.
Stats shows (http://webrtcstats.com) that even with a STUN server, you still fail in 8% of the case, for the general public. It's much more in enterprise, where you'd better have advanced turn (supporting tunneling through TCP/80 and TLS/443) and even support for HTTP proxy's CONNECT method.
I need to find the port number of a server, I have the host name and the IP address.
Is this possible?
I need this as when I try to connect to this server through putty its throwing a Network error:Connection refused error, which may be because of the wrong port number
So you are looking for the port number the ssh server on that system listens on. Usually that is port 22 (well known ssh port), but you are right, this can be changed in the ssh server configuration. If so there are two possibilities yo have:
ask the administrator of the ssh server for the port number
make a network scan of the server which shows up all open ports. Note however that this can be regarded as offensive behavior and may be blocked in mid way.
But most likely you are facing another problem: some firewall blocking your requests or the ssh server not listening to request from outside at all.
And a side note: a server is a service, often listening on a port, you can interact with it typically by "speaking" a specific protocol. A system might refer to a computer running software, typically reachable via network these days. Many servers can be operated on a system. A system can be identified by its ip address. Many people confuse this and speak of a "server" when referring to such a "system" which is simply wrong and creates confusion from a technical point of view.
I found a tutorial that shows you how to create server and client programs, and make them communicate over a network.
http://www.win32developer.com/tutorial/winsock/winsock_tutorial_1.shtm
I can make a client program connect to, for example, 192.168.0.4 on my local network, and I can make it connect to 74.125.225.96. But what if I wanted to make it communicate with 192.168.0.4 on the network of 74.125.225.96, instead of just the default server on 74.125.225.96? I'm having a difficult time finding the answer with Google.
Is there even a way to do this? If not, then how are Gnutella and Bittorrent, able to connect computers directly together to share files?
To do what you are asking, 74.125.225.96 would have to be assigned to a router that is configured to forward inbound connections on the target server port to the machine that is running 192.168.0.4.
BitTorrent and other file sharing apps use various techniques, like NAT traversal, hole punching, etc to get connections through routers and firewalls. For example, if one party is behind a router/firewall and the other party is not, then the two apps first try to connect to each other in one direction, and if that fails then they reverse roles - client becomes server and server becomes client - and they try again. If that still fails, they could then connect to a middleman server that both parties have access to, and let it delegate the connections.
Some background first. I have a .net client agent installed on each of the machines in the lan. They are interacting with my central server [website] also on the same lan.
It is important for my website to figure out which of the machines can talk to each other. For example, machines of one subnet cannot directly talk to machines of another subnet without configuring the routers and such. But machines in the same subnet should be able to talk to each other directly.
The problem I am facing is when the lan setup is like in Figure 1.
Because Comp1, Comp2 and Comp3 are behind a router, they have got the ipaddress 192.168.1.2 till 192.168.1.4. My client agent on these machines report the same ipaddress back to the server. However, machines Comp4, Comp5 also have the same ipaddresses.
Thus, as far as my server is concerned, there are 2 machines with the same ipaddress. Not just that, because the subnet mask is 255.255.255.0 for all machines, my server is fooled into thinking that Comp1 can directly talk to Comp5, which is not possible.
So, how do I solve this? What do I need to change in my client or in my server, so that I can support this scenario. These two are the only things in my control.
EDIT: Seems that the network diagram
is over simplified and there could be
multiple router/subnet levels. My
original answer will not handle this
scenario. Also, with the restriction
of modifying only the client app or server
app and not tampering with the
routers and firewalls makes
it more difficult.
EDIT2: Using 'arp -a' you can extract
the MAC address of the router. If the
client apps can manage to do this then
the puzzle is solved!
The client app knows the local machine address and passes it to the server app.
The server app knows the remote address when a connection comes in. This would be machine address or a router address.
From these two values you can work out what you ask.
For example:
Server app receives connection from 10.10.10.2 with client supplying 192.168.1.2
Server app receives connection from 10.10.10.3 with client supplying 192.168.1.3
The 'remote address' distinguishes the subnets.
So, all you need to figure out is how to extract the remote address of a client connection. If you are using any of the popular web technologies for your server app then this is very easy.
One approach is for the individual client machines to determine who they can see using a broadcast message. Have each client listen on some particular UDP port, and each client broadcast its presence to whatever the local broadcast domain is. When clients can see each other in this way, they can probably also make TCP connections to each other.
If the server needs to know which clients can talk to each other, just have the clients tell the server.
If the network diagram is complicated enough I think if would be very difficuilt to find what you need.
You should also take into account that Comp1 can establish direct connection to Comp6.
The solution I can suggest is probing. Client receives list of all other clients from server and tries to establish connection to each of them. I think that would be the only way to know which clients are REALLY accessible assuming any number of routers/firewalls/NATs in the network. Doesn'r scale much for a big number of computers of course.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.