Extend the wiremock capabilities to handle the raw TCP traffic.

[Damian Gałka]

What do you think to extend with wiremock capabilities to support the raw TCP traffic (socket-to-socket).
I compared the tools:

https://github.com/mefellows/muxy
https://github.com/Shopify/toxiproxy

unfortunately these have no advanced stubbing and matching mechanism which are already implemented in wiremock.

Would you be interested in such functionality in wiremock? Could I elaborate the expected effort and provide a POC of the solution?

[Tom Akehurst]

There's no doubt this is a project I'd love to work on if I had the time.

WireMock is very coupled to the HTTP model. Do you have any thoughts about how it could be adapted to TCP in general without a ground-up rewrite?

Are there specific protocols on top of TCP you'd like to support? I'm wondering whether mocking at that level might be worth exploring?

[Damian Gałka]

My first thought was about:

1. reading the bytes sent to particular socket
   
2. Wrapping payload into POST HTTP Request
1. the wrapping could be customized by providing other implementation (maybe in the future)
3. Simulate the incoming HTTP Request and apply all the origin mechanism which are already supported in wiremock
4. Unwrap the HTTP Request/Response depends on the endpoint which wiremock calls and write Http body to socket.
1. unwrapping could be also customized by providing other implementation (maybe in the future)

The general my idea is to put tcp facades to enrich/impoverish the requests/responses:

• raw payload => HttpRequest => raw payload
• raw payload => HttpResponse => raw payload (mapping probably needed once to handle the response from proxying service

[Tom Akehurst]

The reservation I have about this is that it assumes quite a bit about the application protocol in use i.e. that's sufficiently similarly structured to HTTP to be able to coerce messages into an HTTP request object.

I guess there's also the implication that it has to be a synchronous request/response protocol, in which case you there needs to be some way of understanding when a request is complete, which varies between application protocols.

I'm definitely curious about supporting other protocols. I got asked about protobuf yesterday, and gRPC is starting to look interesting too. But my suspicion is that there's a lot more value to be added by mocking specific protocols such as these, rather than trying to make sense of raw HTTP traffic.