• Post Reply Bookmark Topic Watch Topic
  • New Topic

Connected vs. Unconnected protocol

 
Marx Villegas
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ranchers!
I'm designing a socket application, and the thing is that sometimes the client requests data from the server, and somtimes the server must send data to a specific client, like some sort of a remote control, do you get the idea?
I know that maybe you've been asked this like a zillion times, but, is there any design principle that let one decide if the right way to go is to design a connected application, or a keep-opening-and-closing-sockets app?
Considering that the data to be transmitted is not much, just a couple of directives like once in an hour, and for less than 50 clients, which could be a good aproach to my problem?
Any help is well appreciated
Regards
XM
 
Santhosh Kumar
Ranch Hand
Posts: 242
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Beneath the java.net package there are two protocols. TCP and UDP. TCP is connection protocol and UDP is not connectionless protocol. TCP handels all package synchronization, retransmitting the lost packets etc whereas if you use UDP protocol, it is all application developers responsibility.

So I would suggest you stick with TCP.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A connection consumes resources on the server. A simple socket might not need much depending on your server, but some systems like databases use huge amounts of memory per connection.

Connecting and disconnecting saves that memory but takes a little time. It might be many thousands of times longer than using an open connection, but still the time on the clock is not that much. Many web pages do it dozens of times for images and frames and such.

Holding a connection for a long time can fail. If there is a network burp or the server shuts down and restarts while you're not looking the client's connection is bad. You have to detect such things and try to refresh the connection.

If a server is holding resources for a connection and the client never calls again, how do we reclaim the resources? Maybe you need a keep-alive signal or a time out.

These are some of the things you have to balance. Open-send-close is simple on both ends and relatively safe. If you can afford the connection resources and desperately need the seconds you'd save on a persistent connection, it might be worth the complexity.

Was that answering the right question?

Oh, and Santhosh was right on about UDP. It is fast and easy and is sometimes used in places where you can afford to lose a message now and then. I'm told online games use UDP for speed, but they have to be written to figure out what's going on even if they don't get every single message or maybe get them out of order.

Let us know what you choose!
[ July 04, 2006: Message edited by: Stan James ]
 
Marx Villegas
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Stan/Santhosh,
your answer was the confirmation I needed of what I thought.
I have one further question: the open/send/close practice means that I should have serversockets in both ends of the application (client and server). Is that a good practice?
Thanks a lot!
XM
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have no problem with playing the client and the server role at both ends. Servers play clients to other partner systems all the time. Desktop and web clients play server much less often, but it's about the only way to for a server to "push" to the client in near-real-time.

You may have some firewall issues at client sites, though. I've only done this in-house where all users are on the same trusted network.

Messaging might be an interesting solution if you can install messaging software on the client. We're big IBM MQ-Series fans here but there are cheaper implementations of JMS.
[ July 05, 2006: Message edited by: Stan James ]
 
Marx Villegas
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot Stan,
my app will run in a trusted network. By now I've programmed my own firewalled-messaging platform. My server sockets know exactly which ip's are allowed to connect, so I refuse any other, just in case...
Again, thanks for your support, it is my first socket application and it's been a very fun challenge, full of threads, protocols, sockets, etc.
Best regards
Marx
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey, keep having fun! I find sockets entertaining at some geek level that is more about bits & bytes than business value. But you gotta have the plumbing underneath to get much business done.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey, keep having fun! I find sockets entertaining at some geek level that is more about bits & bytes than business value. But you gotta have the plumbing underneath to get much business done.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!