Find Jobs
Hire Freelancers

Develop perl code to handle websocket and UDP connections

$100-175 USD

Cancelado
Publicado há mais de 13 anos

$100-175 USD

Pago na entrega
A perl application that acts as a bridge/proxy/relay between a websockets HTML5 client and one of two UDP ports on a server. Some JSON experience required. No database experience required. API development experience suggested. The application receives requests from a websockets client and forwards it to one of two UDP ports based on a "destination" attribute from the JSON data sent from the browser. Needs a simple API that that additional modules can hook into to get access to the raw data sent back and fourth. ## Deliverables # Overview This sounds much more complicated than it is because much of the code already exists as open source/GPL. Since we are releasing this code as GPL as part of a complete package when project is done, other GPL/open source code can be recycled and rolled up into this. This project merely combines other open source projects into this one. The software will be responsible for handing a secure (SSL) HTML5 websocket connection with one or more web browsers (the clients). It will also be responsible for relaying data packets received from a web client and direct the data packet to the correct destination. # Worker skills required: * Advanced Perl * * Utilize 3rd party GPL/open source code # Reusable code Code already exists to handle the HTML5 websocket connections (Perl code exists to handle 99% of this - Mojolicious). Code already exists to handle the two UDP protocols on the two UDP ports. For the required "handler" extensions, perl code already exists for these two protocols. For the "user" extension, much of this exists in the Mojolicious project. It just needs to be converted to this code format. # Dataflow A user (web browser, email, etc) makes a connection to the perl code through an interface (expendable with plugins or extensions). After the user is authenticated, it will be allowed to receive and send data packets with the service (the code the Worker will be developing). Any data source (another web client, or external data source) can send to data to any other destination (including other users, or data destinations). # Deliverables * Core perl script that acts as a traffic router between all the extensions. * One "user" extension that is responsible for handling multiple HTML5 SSL/TLS websocket connections. This extension can fork or pre-fork as needed. Potentially using the existing project Mojolicious since it can already do 95% of the work. This module is also expected to authenticate the user using a simple flat text file of user names and hashed passwords, much like an http basic auth so the password is not in plain text if possible. * Two "handler" extensions. Each handler will utilize existing code to connect to an UDP port to send/receive packets. Details on this will be sent directly to the developer/worker as I want to keep this confidential until I'm ready to release the completed software package (still developing the web client javascript). We estimate each of these extensions will consume about 20% of the total work. * A very simple "listener" extension that logs all data packets to a text file. * A configuration file. This configuration file is read by the perl script to load other modules/extensions, what port the web socket is to listen on, and any other configurations to be used by any extension (such as the file location of the user names/passwords), what port the web server should listen on, debug level, etc. # Modular design Internal API or hooks or some sort interface for calling each extension's "send" function. The core code needs to accept three extension types (users, handlers, and listeners). These extension hooks allow users to develop additional code. The user and handler extensions can both be data sources and data destinations. It's up the extension what to do with any data received or how it generates the data. The data will be presented as a "data packet" (see Data Packet Format below). This extension is both a data source and data destination. ## Handler extension The handler extension is responsible for connecting to some data source and monitoring that data source. A data source can be a SQL database, TCP/UDP connection, log file, etc. It needs to be non-blocking so other extensions can continue to run. The core perl code doesn't care about the source, it just wants the data. The extension is a separate file and is included at run time from the perl code. This file would use some sort of hooks to extend the core code. ## User extension Much like the user extension, but in "user" name space for target addressing (see Data Packet Format below). The core code doesn't care where the user is coming from (web, email, or otherwise). The core code just needs to send packets targeted for "user:user name" or "user:*" to the correct extension so that extension can forward to the correct user. We assume that as a user connects to an extension, the extension will need to register that user with the core code to determine where to send any targeted data packets to. The user extension is responsible for authenticating the user and the core code except data from any user extension. A user extension needs to be able to query to core code for a list of all users logged in and available "handlers". It doesn't need to know about any listeners. ## Listener extension Much like the handler extension, the listener extension simply gets access to all traffic regardless of the target. It doesn't generate traffic. The listener extension is responsible for implementing whatever it wants to do when it gets a data packet. # Data Packet Format The hook interface (of whatever method) needs to send one structure (either in array, object, hash, or some easy to understand method) to the proper target(s). The data packet sent from any handler, as well as the from the web client, has the following structure: Source: User or handler name. If it's from a client, it's format is "User:User name" Eg: "User:John Smith". If it's from a handler, it's format is "Handler:Handler Name" Eg: "Handler:My log Monitor". A special source of "Server:*" designates that it came from the core code. This can be used to send commands to applications and handlers that the core code is shutting down and to close any connections or other specific messages. *Timestamp*: Timestamp of the originating packet. In format of "YYYY-MM-DD HH:mm:SS". To be generated by the user or handler extensions (which may get this from their data sources). *Target*: The target of the data packet. This can either be an extension, all extensions, all users or a specific user. All listeners will get all traffic. Format of target: "Type:Name" Examples: "*:* will send to all handlers and users. "User:*" will send to all users, while "User:John Smith" will only be sent to the user "John Smith" if that user exists. "Handler:*" will send to all handler extensions, while "Handler:My log Monitor" will only be sent to the handler "My log Monitor" if that handler client exists. "Listener:*" will send data to all listeners. This can be used for logging by anything, including the core code when starting/stopping services, but no data is actually sent. *Data*: A string of data. No processing is done at the core level. If the source is "Server:*", teh core code should forward to all extensions so they can process any commands - such as shutting down. *Hash*: A string of data. No processing is done at the core level. ## User web client extension requirements and data format * Needs to send and receive data in JSON format. * Develop the interactions for user authentication. Another developer will take those specifications and implement that in the web client. * * Another developer will be responsible for accepting "Server" type commands and processing authentication requests and prompt the user. * A response should always be sent to the client if authOK or authNotOK so it knows if it's to expect a data session to start. * Needs to be able to handle multiple web clients. ## Data packet format for web client interactions Type: data, server - Data: A data packet is attached for processing - Server: A server command. Used to send authentication request Package: Either the data packet from a user or handler extension or the command from the server such as authentication, server is going down, etc. Responses from the web client is in the same format. # Other requirements * Only start one script, which can fork or pre-fork as needed any other script(s) (extensions??). * All code, other than any additional CPAN Perl Modules, should be contained within a folder for easy install, setup, and configuration. # Out of scope * No status messages in response to data packets need to be generated, processed, or handled by the core code. Assume that once delivered to an extension (user, handler, listener), it is sent and can move on. The handler or user extension can generate another data packet as a status message if needed and routed as above. * Installation package - it's not required to generate a software installer. # Priority Develop the standards for user authentication so I can pass this off to the Javascript developer for implementation into a basic web client. This client will be used for testing/development. # Testing Developer/Worker should be able to test this application using Chrome 4.0, other any other HTML5 compliant browser with websocket support, such as Firefox 4 beta, iPad, etc. Test to make sure the browser gets authenticated, and the listener is logging all data packet transactions. # Coding Specifics Psydocode and naming standards will be provided separately so as not to completely give away the project purpose until it's released to the public as a larger package.
ID do Projeto: 3772820

Sobre o projeto

Projeto remoto
Ativo há 13 anos

Quer ganhar algum dinheiro?

Benefícios de ofertar no Freelancer

Defina seu orçamento e seu prazo
Seja pago pelo seu trabalho
Descreva sua proposta
É grátis para se inscrever e fazer ofertas em trabalhos

Sobre o cliente

Bandeira do(a) UNITED STATES
Rancho Cordova, United States
5,0
3
Método de pagamento verificado
Membro desde out. 5, 2010

Verificação do Cliente

Obrigado! Te enviamos um link por e-mail para que você possa reivindicar seu crédito gratuito.
Algo deu errado ao enviar seu e-mail. Por favor, tente novamente.
Usuários Registrados Total de Trabalhos Publicados
Freelancer ® is a registered Trademark of Freelancer Technology Pty Limited (ACN 142 189 759)
Copyright © 2024 Freelancer Technology Pty Limited (ACN 142 189 759)
Carregando pré-visualização
Permissão concedida para Geolocalização.
Sua sessão expirou e você foi desconectado. Por favor, faça login novamente.