Rapid Signaling Service(repost)

**Title:** Client/Server rapid signaling service **Description:** **Concept:** A subscriber will connect to a website and enter a username and password. A JAVA client app will launch and connect to a MS Windows 2003 server running an application to accept the connection in C, C#, VBA or VB.Net. The Java client would immediately receive a small amount of text data to be displayed in a label above the signaling part of the GUI which would describe some “event information?? which will be arriving to the client at a specific time (say 8:30am EST), which is the signal. On the Windows 2003 server, the server-side application in C, C#, VBA or VB.Net will be accepting all the inbound connections from the Java client applications from all over the world. The server app will need to incorporate the use of an C, C#, VBA or VB.Net API to receive information from a data provider. This API will be provided to you. The vital data will be received through the API to the server app which will do a calculation on the data. In the instant after the calculation is complete, this data will be instantaneously transmitted to all of the connected Java clients. The Java client would receive the data and display a signal to the subscriber. It is IMPERATIVE the Java clients receive the signal from the server in the fastest technologically capable way available via TCP/IP protocols. ## Deliverables **Additional Details:** **Server-Side:** The server-side app written in C, C#, VBA or VB.Net will have a small GUI for specific functions. An editable textbox on the GUI will be for the “event information?? which will be broadcast to the Java client. A method will need to be written into the server to update the “event information?? with the Java client in the event the field is updated on the server after the initial connection has been made by the Java client. Additional information will be given to the winning developer as to the formatting of data at the server-app and the client interface. The server-app should send out periodic “heart-beat?? signals to the client so as to maintain the connection and for a visual effect on the client so the subscriber will know that the client is connected. There should also be a testing mechanism that will send a test signal to the clients to see how fast the service is behaving. A way to trigger the signal manually from the server-side app will need to be a feature for testing and connection verification. **Client:** The client app will basically be laid out as a spreadsheet with 4 columns and 3 rows. It will be a fixed layout and not editable by the subscriber. At the top of the app will be the label that will have the “event information?? displayed. The rows and columns will be below the “event information?? label. There should also be a “heart-beat?? indicator of some sort at the bottom of the client that will provide connectivity “peace-of-mind?? to the subscriber. The client should attempt to auto-connect in the event it loses connectivity. An error message should be displayed to the client if it cannot connect to the server. There should be a button on the client app labeled “Signal Speed??. When this is clicked, the client app should display in a label below the button the time in ms (milliseconds) that it took for data to be sent to the server (this may be accomplished with a small payload ping test which would not be displayed to the subscriber; i.e. all done in the background and unseen by the subscriber). **Requirements:** Server-side application must be written to run with a GUI on a Windows 2003 server in C, C#, VBA or VB.Net. The client must be written in JAVA to be spawned from a website as this will facilitate the easiest updating of client for subscribers and ensure platform compatibility. If this service of transmitting data to the subscriber is not fast, then the primary requirement of this project will not be met and the project will not succeed. It is a vital requirement that all the connected Java clients (between 50-2500 client connections) each receive the signal in less than 100ms. (Cable, DSL, T1 and greater Internet subscribers). The protocol which is best suited for the transmission of the signal is UDP. The signal should be sent multiple times to ensure that the signal is received by the client. It is acceptable for the client app to make a TCP connection with the server-side app as long as the actual signals are sent out via UDP. 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. 2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables): a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment. b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request. 3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement). ## Platform Server-side application must be written to run with a GUI on a Windows 2003 server in C, C#, VBA or VB.Net. Client must be written in JAVA to be spawned from a website as this will facilitate the easiest updating of client for subscribers and ensure platform compatibility.