0

I have a custom pair of client/server sockets (TJDServerSocket and TJDClientSocket) which wrap the TServerSocket and TClientSocket in the ScktComp unit. I don't have any issues to fix, but would like to know something. I'd like to add a feature to the client side to automatically search the network for any instances of a server socket (specifically my server component).

I'm open to any suggestions, but has to be specific to the use of the ScktComp unit in Delphi 7.

Here's a link to the components of mine.

Jerry Dodge
  • 26,858
  • 31
  • 155
  • 327
  • 1
    IMHO; You shouldn't use serversocket/clientsocket anymore. Use a real socket library like Indy, ICS, Synapse, or some other full featured one. – Warren P Dec 05 '11 at 15:10
  • If I had a nickel for every time someone told me that :D – Jerry Dodge Dec 05 '11 at 15:22
  • Be it upon your own head. :-) – Warren P Dec 05 '11 at 17:41
  • First of all I love challenging projects, building things from the ground up. Second of all, I plan to eliminate that layer and work directly with the WinSock API, which is essentially what everything socket related works around anyway. – Jerry Dodge Dec 05 '11 at 18:44

4 Answers4

6

Never used the TServerSocket and TClientSocket myself, and I don't have the help files within reach, so I can't immediately see if this would work with those components. For a project I did I needed something like that too. I ended up with using UDP to broadcast a discovery request (within the same subnet of course). The server, listening on a particular port for such a request, would reply its data back. When multiple servers would exist (a situation that though rare could occur) the client just picked the server with the required service(s) and the least load. That load was part of the data the server send back. It worked out nice, wasn't all that difficult to write, and turned out reasonably efficient too.

The request protocol is completely up to you. The one I devised allowed clients to send a request detailing the services they need, and servers replying listing their services and the load (= connected clients in active use). After selecting the server to talk to, a client would register itself for the services it needed, and could use them after that.

Hope this helps.

Arjan de Haan
  • 120
  • 1
  • 5
  • Sounds like a decent schema, mine will be for synchronizing a cross-network app for displaying basic info, like instant messages, meeting announcements, file copy, whatever I might need to do. It would also work great for my cross-network speed testing system - each app is running both a server and a client socket, and many need to connect directly to each other. – Jerry Dodge Dec 05 '11 at 08:06
  • 1
    A cheap and dirty version of service discovery via UDP broadcast is fine on single segment home lans and small office networks, but may not function in corporate networks, depending on their firewalls, and UDP routing, and physical LAN layout. – Warren P Dec 05 '11 at 17:42
  • I **did** mention that it had to be on the same subnet. And I used it on a network in a foodprocessing plant; some LAN configuration might apply indeed. – Arjan de Haan Dec 06 '11 at 11:55
2

There are some standard protocols for service discovery. See for example: http://en.wikipedia.org/wiki/Zero_configuration_networking

Mad Hatter
  • 772
  • 5
  • 5
0

Mailslots is a nice option here. It'll broadcast to every PC on your subnet. See Jeroen's answer to this question: Suggestions on writing a TCP IP messaging system (Client/Server) using Delphi 2010

Community
  • 1
  • 1
Chris Thornton
  • 15,620
  • 5
  • 37
  • 62
0

Searching is as easy as port scanning.

If you don't like the brute force approach, the server can register itself to a well known service application (could be a web server), and the client can connect to the service application to ask. It's quieter than broadcasting.

With more information, such as details about the network (who's it for?), I can suggest a more precise answer.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • Well since these components are universal for any type of project, it would need to be something to search as distant as possible. I'm sure I would at least have to search within the subnet, but I do expect it to be in use on larger corporate networks. – Jerry Dodge Dec 05 '11 at 18:46
  • And technically, these components can work over the internet (via using NAT policies etc.) as well, but I don't expect this service scanner to be able to search the internet through billions of IP's :P Just the immediate subnet. – Jerry Dodge Dec 05 '11 at 19:51
  • Port scanning is not the way to go then. That would probably only be viable for personal use. My second suggestion would work perfectly though. Offer the registration/discovery API as a value added service or charge them monthly for it. – Marcus Adams Dec 05 '11 at 21:11