Welcome to MDProxy Home Page



MDProxy works as a proxy for many devices in a server machine, abstracting all this devices to be tcp/ip reachable sources.  It support "multicast " and "issolation" communication.

Actually it can work opening:



Why MDProxy was created?

MDProxy was created due as a part of another bigger project that reads many rs232 ports.

The project works with an industrial machine, it reads some data at the start of the process and automatically take care of the rest of the preocess. The problem raise when one of the cheaf wanted to serialize the process.  So, now we have two machines, one behind the other, and only one entry point.

Instead of split rs232 connections, I though that create a proxy to share with N clients could be a better idea, so, here we are.

The other reason, that I think that this proxy is important, is because it abstract the clients from hardware details and anything that could be a problem.

Using MDProxy for testing

This is VERY usefull in TESTING, due you can change a serial device for a PIPE or even a TCP/IP socket connection WITHOUT CHANGING your application!  Now you can send/recive data from PIPE while you are TESTING and you can use rs232 in REAL installation without problems!


Download

Just go to sourceforge download section for this project.

How it works?

Just let us explain using some examples how MDProxy works.

Case 1) Simple connection to one resource.

MDProxy configuration: Is connected to one serial port device (rs232) named "SA" (see protocol spec).

ClientA connects to MDProxy and ask about resource SA (client does not need to know what kind of resource is, just needs it's name).

MDProxy accepts the query so henceforth ClientA and SA are connected.  So, every data that SA sends, will forwarder to ClientA, and vice versa.  Note that the connection is bidirectional.

Case 2) One client to many resources.

MDProxy configuration: Is connected to two serial ports (rs232) named SA and SB.

ClientA connects to MDPRoxy and ask about resource SA and SB (rs232 both). MDProxy accept the connection, so, ClientA and resources SA and SB are connected.

In this case, when SA sends data, this data will be forwarder to ClientA.  The same when SB sends data. (SA and SB don't see each other). BUT when ClientA sends data, both, SA and SB will recive that.

Case 3) Many clients to many resources.

MDProxy configuration: you have 3 serial ports (rs232) named SA, SB and SC.

This example will continue the case 2.  Please, read it before.

Now, ClientB connects to mdproxy asking for resource SB and SC.  Now, ClientB, SB and SC are connected. (Note that SB in shared by ClientA too).

So, when SB sends data, this will be forwarder to ClientA AND ClientB.  BUT, when ClientB send data, that will be forwarder to SB and SC, but NOT to ClientA.  (Client Isolation).


Protocol details

Protocol is very simple at this version.  Please, see "Protocol in the future" to see the direction of new releases.

When a new client is connected, MDProxy will expect for resources query, this must be done using:

1000 R1 R2 R3 R4 R5...

Where 1000 is the "header" for query for resources and Rn are the name of the resources (SA, SB and SC in the examples before).

If all is OK, you will recive "1001", if something is wrong (ie. the resource name that not exist) you will recive "1002 R1 R2.." where 1002 is a NOTOK response, and Rn are the name of the problematic resources.

If you recive 1002 response, with n resources, and n is minor that the number of resource that you asked for, the resources not in 1002 message where connected OK.

Important! READ IT!

Once the connection are established, all data will be raw forwarder, so, if you where conected to 2 or more devices, the proxy will no indicate from where of the devices come from! Please, see "Protocol in the future" to see the direction of new releases.

Protocol in the future

The protocol actually has 2 major inconvenients:

* The are no autentication and/or encryptation when you connect to proxy or during it's operation.  Please, be carefull with that.  Perhaps using ipchains would help at least filter by ip.

* When a connection sends data to MDProxy (resource or client), and it is forwarder to the entities associated with this connection, the data will be "raw" forwarded to ALL the connected devices/clients.  So, if you where conected to 2 or more devices, the proxy will NOT indicate from where of the devices comes! or if you send data, this data will be forwarder to ALL of the devices that you were connected!
This WAS INTENTIONAL done to be "legacy" compatible, so, if you have electronic devices or application that you need to use, MDProxy will be transparent for them.

Obviusly, the future in the protocol will be considering this two situation:

* Add ssl connection and login to secure communication between client and proxy.
* Add a "resource identification" to know which of the devices has sended data or to be able to select the device/s you want to send data.
This "resource identification", will only work in client/proxy connections.  For resources connections will strip the protocol data, and sended only data, just to be "legacy" compatible with devices/applications connected to ie. rs232.


Project Home Page

http://mdproxy.sourceforge.net/

Contact

Please, do not hesitate to contact me at aguirrel at xuar.com.ar .