Pinned Repositories
copc-validator
TypeScript package to validate COPC files in NodeJS or Browser environments
16bitVirtualMachine
Originally an assignment from my Computer Systems class at Coe College, it's one of the largest individual projects I've worked on.
cesium-martini
On-the-fly meshing of raster elevation tiles for the CesiumJS virtual globe
CS390-WritingCenter
Writing Center project for CS390 Software Engineering
geotiff.js
geotiff.js is a small library to parse TIFF files for visualization or analysis. It is written in pure JavaScript, and is usable in both the browser and node.js applications.
HTTPServer
HTTP Python Server for CS235
LWSPP
The Lightweight Subscribe and Publish Protocol (LWSP1.1) We envision a system that allows users to engage in real-time, synchronous chats with any number of users. In this environment, a central server maintains connections and relays messages to the appropriate clients. Multiple independent conversations (i.e. chatrooms) can be maintained by the server simultaneously, but users can only see the messages associated with the chatroom they to which they are currently a member. This protocol uses the Transmission Control Protocol (TCP) on port 2028. The service works as follows: 1. The client initiates a persistent connection to the server by sending a JOIN message. The JOIN message includes two strings: chatRoomName and UserName. The chatRoomName is the name of the chatroom to subscribe to. The username is a string intended to identify the client to other subscribers. a. If the chatRoomName does not exist on this server, the server will establish a new room and respond with the message “OK \t” + chatRoomName +“ created” b. If the client attempts to join a chatroom with a UserName that is not unique to that chatRoom, the server will respond with a message “Denied \t username not unique”. The server will then terminate the connection. c. If the chatRoomName already exists and the username is unique, the server will respond with the message: “OK \t joined ”+chatRoomName. d. The server will associate the username and chatroom with the client’s IP address 2. Using a connection established by a JOIN message, the client can terminate the session using the EXIT message. The EXIT message has no additional parameters. a. Upon receiving the EXIT command, the server will publish the message to all members of the chatroom: “LEFT” “\t”+ username b. The server will then remove this client from a chatroom and close the connection. c. If there are no remaining clients in a room, it will be closed permanently. 3. The client can create a transient connection to the server using the SEND command. The SEND command is accompanied by a message of no more than 250 ASCII characters. Upon receiving SEND, the server will: a. Use the IP address from the client to confirm that the client is registered with a chatroom. b. If the client is registered, the server will relay the message string to all members of that chatroom with the format: “SENT” +”\t”+ username +”\t”+ message and then end the connection. c. If the server is unable to confirm this registration, it will reply: “REJECTED: No registered chatroom” and end the connection. d. If the server is unable to send a message to a registered member of the chatroom, it will behave as if the member sent an EXIT command. 4. The client can request to know the members of their chatroom by sending the WHO message. This creates a transient connection to the server and has no additional parameters. a. Upon receiving the WHO message, the server will use the IP address from the client to confirm that the client is registered with a chatroom. b. After confirm that the client is a member of a chatroom. the server will reply with a list of the usernames that are in the chatroom with the client. The response will take the format: “MEMBERS\t” + [csv list of usernames] c. If the server is unable to confirm membership, it will reply: “REJECTED: No registered chatroom” d. The server will end the connection after a reply has been sent. 5. A client can establish a transient connection to request a list of active chatrooms by sending a LIST message to the server. The LIST message has no additional parameters a. Upon receiving a LIST message, the server will respond with the message: “ROOMS/t”+ [csv list of rooms] b. After sending the reply, the server will terminate the connection. Any messages received that are not in compliance with this protocol should result in a response from the Server: “HUH?”. 1. If the deviant message occurs while in an active session (i.e. after the client has JOINED, but before they have EXITED), the connection should be maintained 2. If the deviant message occurs outside of an active session, the server should terminate the connection after sending the status message.
martini
A JavaScript library for real-time RTIN terrain mesh generation. Forked for use with cesium-martini
resium
React components for 🌏 Cesium
themrcam
My Public Repository
TheMrCam's Repositories
TheMrCam/16bitVirtualMachine
Originally an assignment from my Computer Systems class at Coe College, it's one of the largest individual projects I've worked on.
TheMrCam/cesium-martini
On-the-fly meshing of raster elevation tiles for the CesiumJS virtual globe
TheMrCam/CS390-WritingCenter
Writing Center project for CS390 Software Engineering
TheMrCam/geotiff.js
geotiff.js is a small library to parse TIFF files for visualization or analysis. It is written in pure JavaScript, and is usable in both the browser and node.js applications.
TheMrCam/HTTPServer
HTTP Python Server for CS235
TheMrCam/LWSPP
The Lightweight Subscribe and Publish Protocol (LWSP1.1) We envision a system that allows users to engage in real-time, synchronous chats with any number of users. In this environment, a central server maintains connections and relays messages to the appropriate clients. Multiple independent conversations (i.e. chatrooms) can be maintained by the server simultaneously, but users can only see the messages associated with the chatroom they to which they are currently a member. This protocol uses the Transmission Control Protocol (TCP) on port 2028. The service works as follows: 1. The client initiates a persistent connection to the server by sending a JOIN message. The JOIN message includes two strings: chatRoomName and UserName. The chatRoomName is the name of the chatroom to subscribe to. The username is a string intended to identify the client to other subscribers. a. If the chatRoomName does not exist on this server, the server will establish a new room and respond with the message “OK \t” + chatRoomName +“ created” b. If the client attempts to join a chatroom with a UserName that is not unique to that chatRoom, the server will respond with a message “Denied \t username not unique”. The server will then terminate the connection. c. If the chatRoomName already exists and the username is unique, the server will respond with the message: “OK \t joined ”+chatRoomName. d. The server will associate the username and chatroom with the client’s IP address 2. Using a connection established by a JOIN message, the client can terminate the session using the EXIT message. The EXIT message has no additional parameters. a. Upon receiving the EXIT command, the server will publish the message to all members of the chatroom: “LEFT” “\t”+ username b. The server will then remove this client from a chatroom and close the connection. c. If there are no remaining clients in a room, it will be closed permanently. 3. The client can create a transient connection to the server using the SEND command. The SEND command is accompanied by a message of no more than 250 ASCII characters. Upon receiving SEND, the server will: a. Use the IP address from the client to confirm that the client is registered with a chatroom. b. If the client is registered, the server will relay the message string to all members of that chatroom with the format: “SENT” +”\t”+ username +”\t”+ message and then end the connection. c. If the server is unable to confirm this registration, it will reply: “REJECTED: No registered chatroom” and end the connection. d. If the server is unable to send a message to a registered member of the chatroom, it will behave as if the member sent an EXIT command. 4. The client can request to know the members of their chatroom by sending the WHO message. This creates a transient connection to the server and has no additional parameters. a. Upon receiving the WHO message, the server will use the IP address from the client to confirm that the client is registered with a chatroom. b. After confirm that the client is a member of a chatroom. the server will reply with a list of the usernames that are in the chatroom with the client. The response will take the format: “MEMBERS\t” + [csv list of usernames] c. If the server is unable to confirm membership, it will reply: “REJECTED: No registered chatroom” d. The server will end the connection after a reply has been sent. 5. A client can establish a transient connection to request a list of active chatrooms by sending a LIST message to the server. The LIST message has no additional parameters a. Upon receiving a LIST message, the server will respond with the message: “ROOMS/t”+ [csv list of rooms] b. After sending the reply, the server will terminate the connection. Any messages received that are not in compliance with this protocol should result in a response from the Server: “HUH?”. 1. If the deviant message occurs while in an active session (i.e. after the client has JOINED, but before they have EXITED), the connection should be maintained 2. If the deviant message occurs outside of an active session, the server should terminate the connection after sending the status message.
TheMrCam/martini
A JavaScript library for real-time RTIN terrain mesh generation. Forked for use with cesium-martini
TheMrCam/resium
React components for 🌏 Cesium
TheMrCam/themrcam
My Public Repository
TheMrCam/themrcam.github.io
GitHub Pages site for cameronwoodbury.com
TheMrCam/wabbit-ts
Compiler for Wabbit to LLVM, created for David Beazley's Write a Compiler course (March 2024)