Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Sending messages

Status
Not open for further replies.

JimHorton

Programmer
Jan 29, 2000
991
US
Hi all,
What is the best way to send messages, actually data and a fair amount of it, over a tcpip network? A simplified model of what I have is, a server machine that collects thousands of records of data per hour, say from a usb port or some other external device. This data has a location# and then a string of info, and must be routed to one of may client pc's.

I want to push that data to 100 or more client machines, but only the data specifice to that client PC's location#. The data is coming in possibly several records per second, and each client pc must be refreshed every 5 sec. or so. The current ad-hoc solution is to store this data on a database at the server, and have the clients poll the server over a wan. You can see that 100 or more clients hitting this box every 5 seconds to do an index scan and possibly a fetch is going to be a burden, not to mention wan traffic bottlenecks.

What I'd like to do is just hold the data from the usb in some sort of memory array with a Location# and the string of data, and as data for, say, Location# 20 comes in, send that data over the wire to the client at that location, and have something there waiting for these messages. This way the database isn't hit at all, and network traffic from polling is down because I'd be pushing the data.
Thanks for any ideas,
-Jim
 
Why not use MSMQ or IBM MQSeries?

Each PC can, I believe, filter the MQ messages so that they will only see what's destined for them.
 
Temps,
We've looked at that on the surface level, but It's my understanding that msmq won't talk to AIX, and from what I could see of MQ series, it requires a database connection.

The basic architecture is an IBM p670 with Informix, and a minimum of 130, but realistically will be about 200 pc's with windows 98 or 2000, having a VB program that will collect this data. We want informix to notify, say, pc #65 that an order or truck location has changed. This pc will only care about a certain group of orders or trucks, and informix will know which pc's care about which trucks/orders.

So, an update of Order table or Truck Location table will fire a trigger in informix, upon which we'd like a simple tcpip message to go to the pc or pc's that need to know about that truck/order. This message would be, at it's simplest, ascii text with Ord#, Truck#, TruckLocationID--all within 5 minutes of the actual update time.

We don't want 200 pc's polling informix every 5 minutes, nor do we want 200 db connections. Some sort of 'push' technology or webcasting, but without the web--no open browsers, etc. If we could use AOL's Instant messanger without the screens, just behind-the-scenes text that can be captured by the VB program on the pc, that would be ideal. For some reason AOL won't give us the source code [surprise]. Thanks for any input,
--Jim
 
I would just use TCP and have a small app on the client machine just listen on a given port for the data. Have your collector push the data out. Now you have the choice of doing a little more coding work but making the app a little less resource hungry and maybe even faster by using UDP. But you would have to build in your own acknowledgement system when the client recieved information it would reply to the server. If the server didn't get a responce in a given time frame it would resend the data. You also have to have your client capible of recieving the data multiple times and be able to recognise it as a resend and ignore it. Using TCP will do the guarenty delivery but requires you to have the ports open.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top